|Summary:||WebSocket: Client does not support 401 Unauthorized response.|
|Product:||WebKit||Reporter:||Martin Banky <Mythiclese>|
|Component:||WebCore Misc.||Assignee:||Nobody <webkit-unassigned>|
|Severity:||Normal||CC:||achristensen, andrewchen5678, ap, becky, bfulgham, dbates, dieter, harris.max, he, heiko-bugs.webkit.org, ian, jaf, james.x.anderson+bugzilla, Kilian.Brachtendorf, manian, me, oskarbjs, ossy, patrakov, piota, revanscript, Ryan.Slominski, svarunan, webkit-bug-importer, wilander, yutak|
|Version:||528+ (Nightly build)|
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 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:email@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
Comment 11 Eugene 2018-10-08 19:00:58 PDT
It's an important bug, why is it ignored for so long? 6 years
Comment 12 Jeremy Friesner 2018-10-11 11:02:03 PDT
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!
Comment 13 andrewchen5678 2020-02-14 09:45:15 PST
Any update on this? Yesterday I was testing with noVNC with http authentication and noticed this issue.
Comment 14 Becky 2020-02-19 11:19:31 PST
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.
Comment 15 James 2020-09-28 13:23:35 PDT
Still causing an issue with code that works just fine in Chrome (barring iOS Chrome which uses webkit) and Firefox
Comment 16 firstname.lastname@example.org 2020-10-27 11:02:52 PDT
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