Bug 219577 - Safari implicitly normalizes character in XHR request
Summary: Safari implicitly normalizes character in XHR request
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: Safari 14
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-06 04:00 PST by Daniel
Modified: 2020-12-07 13:52 PST (History)
4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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!