580234 - WebSocket() constructor should throw SYNTAX_ERR if URL has zero or one slash after 'ws:' or 'wss:'

Status: RESOLVED INVALID

(Core :: General, defect)

Description

[Simon Pieters [:zcorpan]]

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

Comment 1

[Simon Pieters [:zcorpan]]

Also see https://bugs.webkit.org/show_bug.cgi?id=42636

Comment 2

[Boris Zbarsky [:bzbarsky]]

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?

Comment 3

[Wellington Fernando de Macedo]

Yes, I agree with Boris Zbarsky.

Comment 4

[Simon Pieters [:zcorpan]]

(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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> [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.

Comment 6

[Simon Pieters [:zcorpan]]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17772#c5
http://web-platform.test:8000/websockets/constructor/017.html