User-Agent: Opera/9.80 (Macintosh; Intel Mac OS X; U; en) Presto/2.6.30 Version/10.60 Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; en-US; rv:2.0b2pre) Gecko/20100719 Minefield/4.0b2pre Firefox implies the slashes if they're missing in WebSocket URLs. new WebSocket('ws:example.org/'); new WebSocket('ws:/example.org/'); Apparently no slashes means no authority (user/pass+host+port), which doesn't make sense for websocket, and websocket requires an absolute URL. So I think the above cases should throw SYNTAX_ERR. Reproducible: Always
Where does the spec say to do it? URL parsing in browsers in general implies '/' as needed after the ':' for schemes known to have an authority. You can test that with this HTML: <a href="http:mozilla.org">Click me</a> Why should websocket url parsing be different?
Yes, I agree with Boris Zbarsky.
(In reply to comment #2) > Where does the spec say to do it? I think it says it here: "If the url string is not an absolute URL, then fail this algorithm. [WEBADDRESSES]" http://www.whatwg.org/specs/web-apps/current-work/complete/network.html#parse-a-websocket-url's-components However, it's not well-defined since "resolve an address" in http://www.whatwg.org/specs/web-apps/current-work/complete/urls.html#resolve-a-url is a red box. :-( > URL parsing in browsers in general implies '/' as needed after the ':' for > schemes known to have an authority. You can test that with this HTML: > > <a href="http:mozilla.org">Click me</a> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/568 It resolves to http://software.hixie.ch/utilities/js/live-dom-viewer/mozilla.org for me in Opera, Chrome and Firefox. (However, if I change it to https:mozilla.org then Firefox and Chrome make it https://mozilla.org while Opera makes it http://software.hixie.ch/utilities/js/live-dom-viewer/https:mozilla.org -- from what I understand it should really just change the scheme and path.) > Why should websocket url parsing be different? It currently is different from http: based on the above test.
> [WEBADDRESSES]" Right, so the relevant spec is <http://www.w3.org/html/wg/href/draft> > It resolves to http://software.hixie.ch/utilities/js/live-dom-viewer > /mozilla.org for me Ah, interesting. For authority urls for backwards compat reasons, "protocol:foo" resolved as "protocol://foo" if the base url is not a "protocol:" url and as a relative URL otherwise. The websocket situation is no different: wss:foo resolved relative to a wss: url would resolve as relative, but resolves as absolute relative to any other base. It doesn't seem to me that http://www.whatwg.org/specs/web-apps/current-work/complete/urls.html#absolute-url was written with the de-facto behavior of authority urls in mind. I filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=10213 to sort this out.