RESOLVED WONTFIX 219577
Safari implicitly normalizes character in XHR request 
https://bugs.webkit.org/show_bug.cgi?id=219577
Summary Safari implicitly normalizes character in XHR request
Daniel
Reported 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.
Attachments
Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 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.
Daniel
Comment 2 2020-12-06 11:37:41 PST
(In reply to Alexey Proskuryakov from comment #1) Understood. Thanks!
Note You need to log in before you can comment on or make changes to this bug.