Bug 219577

Summary: Safari implicitly normalizes character in XHR request
Product: WebKit Reporter: Daniel <birowsky>
Component: Page LoadingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WONTFIX    
Severity: Normal CC: ap, beidson, mmaxfield, smoley
Priority: P2    
Version: Safari 14   
Hardware: All   
OS: All   

Description Daniel 2020-12-06 04:00:32 PST 
I picked this character "〉" as a separator for my combo-key-field for my DynamoDb database.

That character surfaces in the browser as part of a next-page-query token. (in an endless scroll list view)

Chrome properly sends that character to the backend (as part of the next-page-query token).

However, Safari, sends that character as this character: "〉", which is different, and as a result, my backend is unable to recognise it.

Why is the browser changing the character? Is this behaviour expected? Did I miss declaring a char-set somewhere?

Probably an important finding is that running '〉' === '〉' returns true in Safari.
Comment 1 Alexey Proskuryakov 2020-12-06 10:55:39 PST 
The original character is the deprecated U+232A RIGHT-POINTING ANGLE BRACKET, and normalizes to U+3009 RIGHT ANGLE BRACKET.

While there is a difference in behavior with browsers that don't normalize text, the best fix is probably on the database side, to not use a deprecated character.
Comment 2 Daniel 2020-12-06 11:37:41 PST 
(In reply to Alexey Proskuryakov from comment #1)

Understood. Thanks!