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

RESOLVED INVALID

Status

()

Core
General
RESOLVED INVALID
7 years ago
3 years ago

People

(Reporter: Simon Pieters, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
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
(Reporter)

Comment 1

7 years ago
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.
(Reporter)

Comment 4

7 years ago
(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.
(Reporter)

Comment 6

3 years ago
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17772#c5
http://web-platform.test:8000/websockets/constructor/017.html
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.