LGTM2 On Mon, Oct 7, 2024, 11:51 PM Daniel Bratell <bratel...@gmail.com> wrote:
> LGTM1 > > /Daniel > On 2024-10-08 02:11, 'Daniel Clark' via blink-dev wrote: > > > Contact emails > > dan...@microsoft.com > Explainer > > None > Specification > > https://url.spec.whatwg.org/#forbidden-host-code-point > Summary > > Per spec <https://url.spec.whatwg.org/#forbidden-host-code-point>, 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 > <https://wpt.fyi/results/websockets?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2024-websockets> > and URL > <https://wpt.fyi/results/url?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2023-url> > focus areas. > > To bring Chromium into spec compliance, ideally we would ban spaces from > all special <https://url.spec.whatwg.org/#is-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 > > Blink>Network > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork> > 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 > <https://issues.chromium.org/u/0/issues/40124263#comment31> 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 > <https://wpt.fyi/results/websockets?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2024-websockets> > and URL > <https://wpt.fyi/results/url?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2023-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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? > > 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 > <https://chromestatus.com/>. > > > -- > 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+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW4PR00MB1455962E8DC964769C03C508C57E2%40MW4PR00MB1455.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer> > . > > -- > 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+unsubscr...@chromium.org. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/962bb212-d0fc-41ae-8ba9-c347806f5432%40gmail.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. 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.
