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)
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:
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
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?
This is supported in Chrome since late 2014 https://code.google.com/p/chromium/issues/detail?id=123862
The following browsers support this:
The following does not:
Is this on anyone's agenda?
This bug is causing me pain. Will this ever be fixed?
Just to clarify, this bug is reporting that HTTP Basic Authentication does not work in Safari over WebSockets, correct?
@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.
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:firstname.lastname@example.org")`, 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.
A workaround for now would be to send a fetch request or xhr with credentials before the first websocket.
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.
So, are there still no plans to implement this? All other browsers / devices except Safari and/or iOS support this.
It's an important bug, why is it ignored for so long? 6 years
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.
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.