This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I would like to have clearer language for URLs regarding their supported <scheme> component. I.e. I would like it to be clear from the draft what happens if you use any of the following: "mailto:foo@example.org" "about:blank" "tag:example.org" "tel:+316..." "data:text/html,..." My preferred solution would be to throw unless the URL scheme is one of a whitelist which contains: http https ftp file (implementation specific, must throw a SYNTAX_ERR if the current scheme is not file) We can add to this whitelist in the future, such as the blob URL scheme.
I don't see why this whitelist idea is desirable, and doing this would certainly break existing Gecko extension XMLHttpRequest consumers. Why shouldn't other protocols be supported, exactly?
We could solve this any number of ways, but for non-extension web content it would be good to have a clear answer to what should happen to the example cases I gave (i.e. mailto URLs and such). Having a whitelist makes the answer very simple. Having it open ended does not and could lead to interoperability problems.
Fair enough. For what it's worth, Gecko's current behavior is that every protocol implementation has an associated boolean flag indicating whether the protocol returns data. Protocols that do not end up throwing when open() is called on a URI for those protocols. Unknown protocols are presumed to not return data (since we have no way to get the data). So for your examples in comment 0, and assuming no extensions that implement additional protocols are installed, we would throw on everything except about: and data:.
Opera and WebKit pass through URLs that are legal and fail at the request layer (i.e. after send() is invoked) for unsupported schemes. Opera supports data URLs. The concept Mozilla has could work, but a) is not part of URI scheme registry so will be difficult and b) cross-origin requests for web content can only work by virtue of CORS which only works for HTTP. I think the solution here then is to remove the restriction on schemes in the open() algorithm. If we also remove the non same-origin restriction there it follows naturally that everything fails in the request layer as these URLs are not same-origin and cannot support CORS. In proprietary environments such as extensions these URLs could still do something useful as presumably CORS is not (always) followed there.
Proposal for CfC: paragraph 3 of comment 4.
That sounds reasonable to me.
Fixed! (Also for redirects.)