"html" error mode somewhat incompatible with URLs #139
Comments
|
FYI some discussion on the Blink side here: https://bugs.chromium.org/p/chromium/issues/detail?id=795733 https://chromium-review.googlesource.com/c/chromium/src/+/836707 There's a decent rationale for Chrome's current behavior towards the bottom of the first link. Current status: no-one is actively pushing to change either Chrome or spec/WPT here. |
|
Why doesn't this belong on the URL standard side? (I.e. the URL side splitting the query string and then encoding it component-wise and percent-encoding each component in a mode that encodes |
Oh, it wouldn't. |
|
Currently https://url.spec.whatwg.org/#query-state does not distinguish between So we could solve this in the URL Standard instead if we accept that we need to encode code point for code point (to avoid encoding a (As far as |
|
I created whatwg/url#386 to address this. As far as I can tell Henri is indeed correct that we don't need to touch the Encoding Standard for this. |
See whatwg/encoding#139 for rationale and whatwg/url#386 for the change to the URL Standard. (I found all these resources in part due to @rakuco's work on trying to align Chrome with the earlier iteration of the specification.)
See whatwg/encoding#139 for rationale and whatwg/url#386 for the change to the URL Standard. (I found all these resources in part due to @rakuco's work on trying to align Chrome with the earlier iteration of the specification.)
See whatwg/encoding#139 for rationale and whatwg/url#386 for the change to the URL Standard. (I found all these resources in part due to @rakuco's work on trying to align Chrome with the earlier iteration of the specification.)
See whatwg/encoding#139 for rationale and whatwg/url#386 for the change to the URL Standard. (I found all these resources in part due to @rakuco's work on trying to align Chrome with the earlier iteration of the specification.)
If the input to the URL parser contains code points outside the non-UTF-8 encoding's value space and the URL parser was invoked using a non-UTF-8 encoding, then those code points end up as &#...;. The problem is that &, #, and ; are also URL separators, but the previous algorithm would only encode #. This ensures that & and ; are also encoded, as some browsers already do, but only if they came about as the result of the encode operation. Tests: web-platform-tests/wpt#10915. Fixes whatwg/encoding#139.
See whatwg/encoding#139 for rationale and whatwg/url#386 for the change to the URL Standard. (I found all these resources in part due to @rakuco's work on trying to align Chrome with the earlier iteration of the specification.)
See whatwg/encoding#139 for rationale and whatwg/url#386 for the change to the URL Standard. (I found all these resources in part due to @rakuco's work on trying to align Chrome with the earlier iteration of the specification.)
…, a=testonly Automatic update from web-platform-testsURL/Encoding: change query state parsing See whatwg/encoding#139 for rationale and whatwg/url#386 for the change to the URL Standard. (I found all these resources in part due to @rakuco's work on trying to align Chrome with the earlier iteration of the specification.) -- wpt-commits: e399a2c694345240639c23cc5e9e4f077a47cf30 wpt-pr: 10915
…, a=testonly Automatic update from web-platform-testsURL/Encoding: change query state parsing See whatwg/encoding#139 for rationale and whatwg/url#386 for the change to the URL Standard. (I found all these resources in part due to rakuco's work on trying to align Chrome with the earlier iteration of the specification.) -- wpt-commits: e399a2c694345240639c23cc5e9e4f077a47cf30 wpt-pr: 10915 UltraBlame original commit: 13f3705568922e770ec97af2aad3e09e0449caa6
…, a=testonly Automatic update from web-platform-testsURL/Encoding: change query state parsing See whatwg/encoding#139 for rationale and whatwg/url#386 for the change to the URL Standard. (I found all these resources in part due to rakuco's work on trying to align Chrome with the earlier iteration of the specification.) -- wpt-commits: e399a2c694345240639c23cc5e9e4f077a47cf30 wpt-pr: 10915 UltraBlame original commit: 13f3705568922e770ec97af2aad3e09e0449caa6
…, a=testonly Automatic update from web-platform-testsURL/Encoding: change query state parsing See whatwg/encoding#139 for rationale and whatwg/url#386 for the change to the URL Standard. (I found all these resources in part due to rakuco's work on trying to align Chrome with the earlier iteration of the specification.) -- wpt-commits: e399a2c694345240639c23cc5e9e4f077a47cf30 wpt-pr: 10915 UltraBlame original commit: 13f3705568922e770ec97af2aad3e09e0449caa6
For some reason I only just realized that the current "
html" error mode results in URLs where&(and;) is not escaped. There's quite a few server-side libraries that split on∧. Maybe that means we should continue to offer an error mode specifically for URLs that in addition to outputting this sequences, also percent-encodes the∧as Chrome appears to be doing.On the other hand, Firefox has shipped the currently specified behavior and we didn't get bug reports.
The text was updated successfully, but these errors were encountered: