URL/Encoding: change query state parsing #10915
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Note: I looked into removing Perhaps further cleanup here can be done as part of #10636. |
|
This needs to change #10891 as well. I haven't corrected it there to keep the state of the test suite consistent. |
39db988 to
361b63f
Compare
|
That's now done. This as well the URL Standard change are ready for review. |
|
Note to self: once this is reviewed and landed, do some work on #4934 again. |
0551797 to
bd7ea53
Compare
|
(I merged the commits together so that "rebase and merge" can be used by an owner. This needs an override due to build timeouts. However, please do not merge this before I remove that label.) |
|
Also, thanks @inexorabletash for the speedy review! |
annevk
added a commit
to whatwg/url
that referenced
this pull request
May 22, 2018
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.
bd7ea53 to
d5b8565
Compare
|
I rebased this to address a merge conflict in |
annevk
added a commit
to whatwg/url
that referenced
this pull request
May 23, 2018
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.
annevk
added a commit
to whatwg/url
that referenced
this pull request
May 23, 2018
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.)
d5b8565 to
6dc57cd
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.)