- From: Dan Clark <notifications@github.com>
- Date: Wed, 21 Aug 2024 11:17:21 -0700
- To: whatwg/url <url@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/url/issues/599/2302690663@github.com>
I am doing some work in the Chromium project to try to bring the handling of space characters more in line with the URL parsing standard, and to complete that it would be very helpful if we had an idea of the way this issue is likely to be resolved. As @TimothyGu noted [here](https://github.com/whatwg/url/issues/599#issuecomment-846372280), Chromium allows spaces in hostnames for both `http`/`https` and in `file` URLs. Ideally we would change the Chromium behavior to match other browsers by banning spaces for all [special](https://url.spec.whatwg.org/#special-scheme) URLs. However, this is risky to do for `file` because of the issue raised in this thread of potential spaces in NetBIOS names; and if this issue is resolved to allow `file` URLs to have opaque hostnames, then changing Chromium to treat space as error in `file` URLs could be a wrong step. I've been trying to work around this by drafting a [Chromium change](https://chromium-review.googlesource.com/c/chromium/src/+/5753305) that only disallows spaces for non-`file` special URLs. However the complexity of scoping the change in that way is higher than we'd like, especially since we're not sure how `file` URLs will end up being handled based on the resolution of this issue. So to decide how we should proceed in bringing Chromium closer to standards compliance, it would be helpful if this issue could be moved towards resolution. Would it be possible for the URL standards experts to comment on which way this should go? -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/url/issues/599#issuecomment-2302690663 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/url/issues/599/2302690663@github.com>
Received on Wednesday, 21 August 2024 18:17:25 UTC