Bug 219577
| Summary: | Safari implicitly normalizes character in XHR request | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Daniel <birowsky> |
| Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Normal | CC: | ap, beidson, mmaxfield, smoley |
| Priority: | P2 | ||
| Version: | Safari 14 | ||
| Hardware: | All | ||
| OS: | All | ||
Daniel
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
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
(In reply to Alexey Proskuryakov from comment #1)
Understood. Thanks!