This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Gecko does percent-encode spaces in scheme data. Blink does not. W3C's web-platform-tests expect them to be encoded. Why does the spec doesn't percent encode them? Isn't it better to be on the safe side?
Is space the only difference? It seems my reference implementation is a bit different here too: https://github.com/annevk/url/blob/master/url.js It only has two escape methods...
WebKit, Blink, and Trident do not escape them. Can you explain how it would be safer to escape them?
FYI https://github.com/w3c/web-platform-tests/pull/767
I have no point for or against percent-encoding spaces here. I probably opened this issue because of the discrepancy with web-platform-tests and Gecko.
Given that Santiago likely opened this due to a test discrepancy, I'd suggest closing this as WONTFIX, for the reason that Anne said: WebKit, Blink, and Trident don't escape them: https://url.spec.whatwg.org/interop/urltest-results/bf8630587b Note: I'd also suggest that we either change that test or add another one, as IE treats a one character scheme as a drive letter. https://url.spec.whatwg.org/reference-implementation/liveview.html can be used to explore browser behavior (that's how I verified IE's behavior with a multi-character scheme).
The test seems fine. IE should simply be fixed.