Last Comment Bug 580234 - WebSocket() constructor should throw SYNTAX_ERR if URL has zero or one slash after 'ws:' or 'wss:'
: WebSocket() constructor should throw SYNTAX_ERR if URL has zero or one slash ...
Status: RESOLVED INVALID
:
Product: Core
Classification: Components
Component: General (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-20 06:32 PDT by Simon Pieters
Modified: 2014-02-03 15:05 PST (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Simon Pieters 2010-07-20 06:32:20 PDT
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 2010-07-20 06:36:37 PDT
Also see https://bugs.webkit.org/show_bug.cgi?id=42636
Comment 2 Boris Zbarsky [:bz] (TPAC) 2010-07-20 09:27:15 PDT
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 2010-07-20 09:38:38 PDT
Yes, I agree with Boris Zbarsky.
Comment 4 Simon Pieters 2010-07-20 12:48:39 PDT
(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 [:bz] (TPAC) 2010-07-20 13:37:47 PDT
> [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.

Note You need to log in before you can comment on or make changes to this bug.