Skip to content
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

Merged
merged 2 commits into from
Jan 28, 2022

Conversation

karwa
Copy link
Contributor

@karwa karwa commented Jan 25, 2022

Copy link
Member

@annevk annevk left a 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.

@domenic
Copy link
Member

domenic commented Jan 25, 2022

Chrome (Presumably - See linked issue)

Which part of which linked issue are you referring to?

@karwa
Copy link
Contributor Author

karwa commented Jan 25, 2022

Chrome and Go forbid C0 controls and \u007F, whether encoded or not

@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.

@domenic
Copy link
Member

domenic commented Jan 25, 2022

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?

@karwa
Copy link
Contributor Author

karwa commented Jan 25, 2022

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 \u0000-\u001F or \u007F - Chrome passes them all.

In the WPT.fyi viewer, these are the ones like:

Parsing: <http://ho%01st/> against <about:blank>

As well as the ones just above them which all seem to look the same (because of the raw C0 controls):

Parsing: <http://ab/> against <about:blank>

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):

I think there is a consensus that the forbidden host code points should include all C0 controls and U+007F, and that now matches the behavior of all browsers. Let's make that change to the specification and then make a separate issue about what we want to do with opaque hosts, where there is less consensus and less spec compliance.

#627 (comment)

@domenic
Copy link
Member

domenic commented Jan 25, 2022

If I changed the tests to the current spec, there would be even more failures for all browsers

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.

@karwa
Copy link
Contributor Author

karwa commented Jan 25, 2022

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.

domenic pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 25, 2022
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.
@domenic
Copy link
Member

domenic commented Jan 25, 2022

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.

@annevk
Copy link
Member

annevk commented Jan 26, 2022

@karwa do you want to file the implementation bugs? https://github.com/whatwg/meta/blob/master/MAINTAINERS.md has pointers.

@karwa
Copy link
Contributor Author

karwa commented Jan 27, 2022

@annevk bugs have been filed.

@annevk annevk merged commit 35e195a into whatwg:main Jan 28, 2022
@annevk
Copy link
Member

annevk commented Jan 28, 2022

Thanks a lot @karwa for your work on tackling this as well as providing all those great tests!

annevk pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 28, 2022
valenting added a commit to servo/rust-url that referenced this pull request Jan 28, 2022
add all C0 controls and add U+007F to is_invalid_domain_char
domenic pushed a commit to jsdom/whatwg-url that referenced this pull request Jan 28, 2022
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Feb 5, 2022
…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
jamienicol pushed a commit to jamienicol/gecko that referenced this pull request Feb 7, 2022
…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
mattwoodrow pushed a commit to mattwoodrow/wpt that referenced this pull request Feb 15, 2022
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Feb 26, 2022
…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
DanielRyanSmith pushed a commit to DanielRyanSmith/wpt that referenced this pull request Feb 28, 2022
jamienicol pushed a commit to jamienicol/gecko that referenced this pull request Mar 1, 2022
…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
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Mar 8, 2022
…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
jamienicol pushed a commit to jamienicol/gecko that referenced this pull request Mar 8, 2022
…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
karwa added a commit to karwa/swift-url that referenced this pull request Mar 19, 2022
karwa added a commit to karwa/swift-url that referenced this pull request Mar 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants