10327 2010-08-09 12:34:28 +0000 supported URL schemes in open() 2011-12-20 19:44:22 +0000 1 1 1 Unclassified WebAppsWG XHR unspecified PC All RESOLVED FIXED P2 normal --- 1 annevk annevk ap bzbarsky mike public-webapps public-webapps-bugzilla oldest_to_newest 37302 0 annevk 2010-08-09 12:34:28 +0000 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. 37304 1 bzbarsky 2010-08-09 12:43:46 +0000 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? 37305 2 annevk 2010-08-09 12:49:43 +0000 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. 37307 3 bzbarsky 2010-08-09 12:56:02 +0000 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:. 37310 4 annevk 2010-08-09 14:37:31 +0000 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. 37351 5 annevk 2010-08-11 11:32:20 +0000 Proposal for CfC: paragraph 3 of comment 4. 37356 6 bzbarsky 2010-08-11 15:15:57 +0000 That sounds reasonable to me. 37932 7 annevk 2010-08-26 13:08:31 +0000 Fixed! (Also for redirects.)