Intent to Ship: Disallow spaces in non-file:// URL hosts
Daniel Clark
Contact emails
Explainer
None
Specification
https://url.spec.whatwg.org/#forbidden-host-code-point
Summary
Per spec, URL hostnames cannot contain the space character, but currently URL parsing in Chromium allows spaces in the hostname. This causes Chromium to fail several tests included in the Interop2024 HTTPS URLs for WebSocket and URL focus areas.
To bring Chromium into spec compliance, ideally we would ban spaces from all special URL hosts, but a difficulty with this is spaces could be used in the host part in Windows file:// URLs (see discussion at https://github.com/whatwg/url/issues/599).
So, the scope of this Intent is for the change to bring Chromium closer to spec compliance by making spaces fail URL hostname parsing for non-file:// URLs only.
For the full change and implementation details, see https://chromium-review.googlesource.com/c/chromium/src/+/5753305
Blink component
TAG review
None. This is implementing previously specced behavior, and Gecko and WebKit already treat spaces in URL hostnames as URL parse errors.
TAG review status
Not applicable
Risks
Interoperability and Compatibility
From an interoperability perspective this is strictly positive: the change brings Chromium closer to spec compliance and interoperable
URL parsing behavior with other engines.
There is some compat risk given this is a web-visible change to existing URL parsing behavior. I believe the risk to be reasonable given that we are now aligning with the 2 other browser engines, and excluding the potentially risky file:// URL case.
In 2021, data was collected about the use of space and other not-allowed-per-spec characters in hostnames. See
here for that data and some discussion. On Windows, space was escaped in 0.004143% of hostnames parsed.
Gecko: Shipped/Shipping
WebKit: Shipped/Shipping
Web developers: No signals
Other signals: This issue is causing Chromium/Edge failures in the Interop2024 HTTPS
URLs for WebSocket and URL focus
areas.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Debuggability
None
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes
Flag name on chrome://flags
None
Finch feature name
kDisallowSpaceCharacterInURLHostParsing
Non-finch justification
None
Requires code in //chrome?
False
Estimated milestones
|
Shipping on desktop |
131 |
Anticipated spec changes
Depending on the result of https://github.com/whatwg/url/issues/599, file:// URLs may either change to follow the same behavior of disallowing spaces, or (more likely) change to be treated as having opaque hostnames which would permanently allow them to have spaces. Either resolution is compatible with this Intent since we are not changing the behavior for file:// URLs.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5083335148437504?gate=5097602358706176
This intent message was generated by Chrome Platform Status.
Daniel Bratell
LGTM1
/Daniel
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW4PR00MB1455962E8DC964769C03C508C57E2%40MW4PR00MB1455.namprd00.prod.outlook.com.
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/962bb212-d0fc-41ae-8ba9-c347806f5432%40gmail.com.
Mike Taylor
LGTM3
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_B_58ZqSUyR7zcfTf3Nz2f01S_fejTy%2B%3D%2BPYYMyvR1SQ%40mail.gmail.com.