Bug 80362 – WebSocket: Client does not support 401 Unauthorized response.

• Component: WebCore Misc.
• Status: NEW

[Martin Banky]

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)

[Yuta Kitamura]

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?

[Oskar Börjesson]

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?

[Max Harris]

This bug is causing me pain. Will this ever be fixed?

[Radar WebKit Bug Importer]

<rdar://problem/31800452>

[Ryan Slominski]

Just to clarify, this bug is reporting that HTTP Basic Authentication does not work in Safari over WebSockets, correct?

[Varunan]

@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:[e-mail]")`, 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.

[Alex Christensen]

A workaround for now would be to send a fetch request or xhr with credentials before the first websocket.

[Varunan]

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.

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.

[Marc Herrmann]

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.

[Eugene]

It's an important bug, why is it ignored for so long? 6 years

[Jeremy Friesner]

This bug is also causing me trouble -- currently our only work-around is to tell our Mac users to download Chrome and use that instead, which is not a very popular response with them.  It would be really awesome if this could be fixed sooner rather than later!

Any update on this? Yesterday I was testing with noVNC with http authentication and noticed this issue.

[Becky]

This is still causing issues and excess work. We've had to implement a whole new auth process for a customer just so that their setup supports Safari. Not everyone uses basic auth but for those who do this is a real issue.

[James]

Still causing an issue with code that works just fine in Chrome (barring iOS Chrome which uses webkit) and Firefox

[[e-mail]]

I use nginx as a reverse proxy with https and want to access a dashboard. But this is with Safari Browser on iOS not possible. I get the error message: websocket not connected. On android devices or via desktop pc everything works fine. Please fix this important bug soon as possible. 

Thanks

Is there any news on this 10 year old issue?  Any explanation as to why you wouldn't want to support this?