This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22488 - The text "if the status code received from the server is not 101 (e.g. it is a redirect), the user agent must fail the WebSocket connection." appears to contradict RFC6455 section 4.1 "If the status c [...]
Summary: The text "if the status code received from the server is not 101 (e.g. it is ...
Status: RESOLVED NEEDSINFO
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-27 08:46 UTC by contributor
Modified: 2013-09-12 21:27 UTC (History)
4 users (show)

See Also:

Attachments

Description contributor 2013-06-27 08:46:57 UTC 
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html
Multipage: http://www.whatwg.org/C#the-websocket-interface
Complete: http://www.whatwg.org/c#the-websocket-interface
Referrer: 

Comment:
The text "if the status code received from the server is not 101 (e.g. it is a
redirect), the user agent must fail the WebSocket connection." appears to
contradict RFC6455 section 4.1 "If the status code received from the server is
not 101, the client handles the response per HTTP [RFC2616] procedures.  In
particular, the client might perform authentication if it receives a 401
status code; the server might redirect the client using a 3xx status code (but
clients are not required to follow them), etc." The expectation from web
developers appears to be that the client will behave like an HTTP client until
the handshake is complete, and browsers seem to be converging on that
behaviour.

Posted from: 2401:fa00:4:1000:b6b5:2fff:feca:47f8
User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1535.3 Safari/537.36
Comment 1 Simon Pieters 2013-06-27 09:24:24 UTC 
This was intentional to avoid security problems, as explained in the warning the next paragraph.

[[
Following HTTP procedures here could introduce serious security problems in a Web browser context. For example, consider a host with a WebSocket server at one path and an open HTTP redirector at another. Suddenly, any script that can be given a particular WebSocket URL can be tricked into communicating to (and potentially sharing secrets with) any host on the Internet, even if the script checks that the URL has the right hostname.
]]

Also see http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/031079.html
Comment 2 Ian 'Hixie' Hickson 2013-07-02 23:36:51 UTC 
> the client will behave like an HTTP client until the handshake is complete,
> and browsers seem to be converging on that behaviour.

Can you elaborate on this?
Comment 3 Adam Rice 2013-08-07 02:43:36 UTC 
(In reply to comment #2)
> > the client will behave like an HTTP client until the handshake is complete,
> > and browsers seem to be converging on that behaviour.
> 
> Can you elaborate on this?

Examples of user expectations:

https://code.google.com/p/chromium/issues/detail?id=128170
https://code.google.com/p/chromium/issues/detail?id=123862
https://code.google.com/p/chromium/issues/detail?id=174956
https://bugzilla.mozilla.org/show_bug.cgi?id=827074

It will take me a few days to gather concrete evidence of current browser behaviour.
Comment 4 Ian 'Hixie' Hickson 2013-08-07 21:06:22 UTC 
WebSocket is not HTTP. It pretends to be, so that it can sneak past legacy network hardware, but it's not HTTP. It's just WebSocket. You don't "upgrade" from HTTP to WebSocket, you are just always WebSocket. It's just that the initial WebSocket handshake happens to look very much like an HTTP upgrade.

The IETF made this much less obvious when they took over the spec, unfortunately.
Comment 5 Ian 'Hixie' Hickson 2013-09-12 21:27:01 UTC 
Please reopen the bug once you have that info, thanks!