-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split forbidden host/domain code points, and add all C0 controls and add U+007F to the latter #685
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. I don't think the conformance requirements end up needing adjusting (and it seems like this fixes a small problem for "valid opaque-host string"), although for "valid domain string" it's a bit unclear due to the imperative nature of its definition.
I'd appreciate a second review.
Which part of which linked issue are you referring to? |
@domenic This is Chrome’s existing behaviour for C0 controls and U+007F in domains. This PR makes no changes to opaque hosts compared to the status quo. Apologies for not making that clearer. |
Hmm. But https://wpt.fyi/results/url?diff&filter=ADC&run_id=5656521351364608&run_id=5648068402741248 shows many new failing tests in Chrome. Are all of those tests that would already fail with the current spec? Maybe it'd be best to separate out the tests PR into one that tests the current spec, and one that tests the change here, so that we can actually see if the change here causes any deltas from the current spec? |
There are more failures because there are more tests, but for the part which is changed by this spec change - domains containing (raw or encoded) code points in the range In the WPT.fyi viewer, these are the ones like:
As well as the ones just above them which all seem to look the same (because of the raw C0 controls):
If I changed the tests to the current spec, there would be even more failures for all browsers. None of them implement the current spec. WebKit was the last one, but @achristensen07 recently changed made the change to reject those code-points (for all hosts, not just domains, which is why WebKit still has one failure, but the consensus from the issue seemed to be to leave those alone for now):
|
Right. That would be helpful. Then we could double-check that the new tests, specific to the changes in this PR, are all passing in Chromium. |
OK, I've put up web-platform-tests/wpt#32539 Same tests as linked for this change, but with expected values that match the current spec. |
These give much more full coverage for host code points. The expectations will be changed in #32524 to follow the spec change proposed in whatwg/url#685; this initial PR gives us a baseline so we can be clear about what the changes are.
Editorially LGTM, let's just rebase web-platform-tests/wpt#32524 on WPT master, confirm that the result is more in alignment with browsers, and then we should be good to merge. Thanks @karwa for doing the work, including the testing against whatwg-url. |
@karwa do you want to file the implementation bugs? https://github.com/whatwg/meta/blob/master/MAINTAINERS.md has pointers. |
@annevk bugs have been filed. |
Thanks a lot @karwa for your work on tackling this as well as providing all those great tests! |
See whatwg/url#685 for context.
add all C0 controls and add U+007F to is_invalid_domain_char
…ode points, a=testonly Automatic update from web-platform-tests URL: More tests of (currently) non-forbidden host code points These give much more full coverage for host code points. The expectations will be changed in #32524 to follow the spec change proposed in whatwg/url#685; this initial PR gives us a baseline so we can be clear about what the changes are. -- wpt-commits: 53a00b35ce2808bbbef9699ac4b6f0d5da46009a wpt-pr: 32539
…ode points, a=testonly Automatic update from web-platform-tests URL: More tests of (currently) non-forbidden host code points These give much more full coverage for host code points. The expectations will be changed in #32524 to follow the spec change proposed in whatwg/url#685; this initial PR gives us a baseline so we can be clear about what the changes are. -- wpt-commits: 53a00b35ce2808bbbef9699ac4b6f0d5da46009a wpt-pr: 32539
See whatwg/url#685 for context.
…oints and add more tests for each, a=testonly Automatic update from web-platform-tests URL: forbid more code points in non-opaque domains See whatwg/url#685 for context. -- wpt-commits: 2a64dae4641fbd61bd4257df460e188f425b492e wpt-pr: 32524
See whatwg/url#685 for context.
…oints and add more tests for each, a=testonly Automatic update from web-platform-tests URL: forbid more code points in non-opaque domains See whatwg/url#685 for context. -- wpt-commits: 2a64dae4641fbd61bd4257df460e188f425b492e wpt-pr: 32524
…oints and add more tests for each, a=testonly Automatic update from web-platform-tests URL: forbid more code points in non-opaque domains See whatwg/url#685 for context. -- wpt-commits: 2a64dae4641fbd61bd4257df460e188f425b492e wpt-pr: 32524
…oints and add more tests for each, a=testonly Automatic update from web-platform-tests URL: forbid more code points in non-opaque domains See whatwg/url#685 for context. -- wpt-commits: 2a64dae4641fbd61bd4257df460e188f425b492e wpt-pr: 32524
Attempt at resolving #627 and #319
(See WHATWG Working Mode: Changes for more details.)
Preview | Diff