Bug 80362

Summary: WebSocket: Client does not support 401 Unauthorized response.
Product: WebKit Reporter: Martin Banky <Mythiclese>
Component: WebCore Misc.Assignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: achristensen, ap, bfulgham, dbates, dieter, harris.max, he, ian, Kilian.Brachtendorf, manian, oskarbjs, ossy, Ryan.Slominski, svarunan, webkit-bug-importer, wilander, yutak
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   

Description Martin Banky 2012-03-05 17:45:26 PST
When opening a WebSocket connection to a server that requires authentication, the connection errors out with "Unexpected response code: 401". This works in Firefox 11 beta 5.

According to RFC6455, section 4.1., "The request MAY include any other header fields, for example, cookies [RFC6265] and/or authentication-related header fields such as the |Authorization| header field [RFC2616], which are processed according to documents that define them.", also in 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.", and in section 4.2.2., "2. The server can perform additional client authentication, for example, by returning a 401 status code with the corresponding |WWW-Authenticate| header field as described in [RFC2616]."

OS: Arch Linux with latest updates.
Browser: Chromium Version 17.0.963.65 and 19.0.1061.0 (125018)
Comment 1 Yuta Kitamura 2012-03-07 15:16:36 PST
We should do this, but how to implement this does not sound obvious to me.

By the way, WebSocket API spec has the following sentence:

    http://www.w3.org/TR/websockets/

    When the user agent validates the server's response during the "establish a 
    WebSocket connection" algorithm, 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.

The wording "not 101 (e.g. it is a redirect)" is a bit vague and there can be two understandings:
(1) the user agent must not perform redirection but must handle the other non-101 HTTP codes as it does in HTTP.
(2) the user agent must fail the WebSocket connection if the status code is not 101.

(2) is against RFC6455 so I assume (1) is right. Hixie, what do you think?
Comment 2 Oskar Börjesson 2015-10-09 05:06:05 PDT
This is supported in Chrome since late 2014 https://code.google.com/p/chromium/issues/detail?id=123862

The following browsers support this:
 Chrome
 Firefox
 Internet Explorer
 Edge
 Yandex

The following does not:
 Safari

Is this on anyone's agenda?
Comment 3 Max Harris 2016-01-04 13:34:46 PST
This bug is causing me pain. Will this ever be fixed?
Comment 4 Radar WebKit Bug Importer 2017-04-24 16:45:44 PDT
<rdar://problem/31800452>
Comment 5 Ryan Slominski 2017-07-10 06:39:21 PDT
Just to clarify, this bug is reporting that HTTP Basic Authentication does not work in Safari over WebSockets, correct?
Comment 6 Varunan 2017-07-26 02:13:16 PDT
@Ryan Slominski, I even have the same issue, Basic auth over websocket is not working in current Safari. Same works in other browsers. I thought of creating a new ticket, but just landed here.

In Safari
Basic auth over pure http works fine. But over websocket its not.

My Plan is to send user/password combo directly in websocket URL
`new WebSocket("ws://username:password@example.com")`, Once i receive http request with "Authorization" header validate it and upgrade to websockets in sockets server. But 

This way http -> websocket upgrade happens only on auth validation.
Comment 7 Alex Christensen 2017-07-26 08:07:00 PDT
A workaround for now would be to send a fetch request or xhr with credentials before the first websocket.
Comment 8 Varunan 2017-07-28 06:40:05 PDT
Alex,
Its a client side code so anyone can bypass XHR request with credentials and directly connect to websocket URL which is visible.

It should a single http request (hand shake) with Authorisation header added and upgrade to websocket on auth success.
Comment 9 Kilian.Brachtendorf 2018-01-26 04:46:44 PST
Any updates on this? A 6 year old bug report and a real blocker in my project. The only "workaround" is to disable authentication if Safari is supposed to be supported.
Comment 10 Marc Herrmann 2018-04-05 04:36:52 PDT
This issue also leads to very high CPU load and energy consumption because of the high frequency of retry attempts for the websocket connection (with a simple javascript). Also, no workaround seems to be possible to prevent this behaviour.
So, are there still no plans to implement this? All other browsers / devices except Safari and/or iOS support this.