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.
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.
Also see https://bugs.webkit.org/show_bug.cgi?id=42636
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]"
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>
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.
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.