80362 2012-03-05 17:45:26 -0800 WebSocket: Client does not support 401 Unauthorized response. 2026-03-04 16:43:14 -0800 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) All All REOPENED InRadar P2 Normal --- 1 Mythiclese webkit-unassigned achristensen andrewchen5678 ap becky bfulgham dbates dieter harris.max he heiko-bugs.webkit.org ian jaf james.x.anderson+bugzilla julian Kilian.Brachtendorf manian me oskarbjs ossy patrakov piota revanscript Ryan.Slominski svarunan webkit-bug-importer webkit wilander yutak oldest_to_newest 571280 0 Mythiclese 2012-03-05 17:45:26 -0800 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) 573293 1 yutak 2012-03-07 15:16:36 -0800 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? 1131880 2 oskarbjs 2015-10-09 05:06:05 -0700 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? 1152496 3 harris.max 2016-01-04 13:34:46 -0800 This bug is causing me pain. Will this ever be fixed? 1300719 4 webkit-bug-importer 2017-04-24 16:45:44 -0700 <rdar://problem/31800452> 1326985 5 Ryan.Slominski 2017-07-10 06:39:21 -0700 Just to clarify, this bug is reporting that HTTP Basic Authentication does not work in Safari over WebSockets, correct? 1332299 6 svarunan 2017-07-26 02:13:16 -0700 @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. 1332340 7 achristensen 2017-07-26 08:07:00 -0700 A workaround for now would be to send a fetch request or xhr with credentials before the first websocket. 1332953 8 svarunan 2017-07-28 06:40:05 -0700 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. 1393501 9 Kilian.Brachtendorf 2018-01-26 04:46:44 -0800 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. 1412034 10 he 2018-04-05 04:36:52 -0700 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. 1467307 11 revanscript 2018-10-08 19:00:58 -0700 It's an important bug, why is it ignored for so long? 6 years 1468083 12 jaf 2018-10-11 11:02:03 -0700 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! 1619049 13 andrewchen5678 2020-02-14 09:45:15 -0800 Any update on this? Yesterday I was testing with noVNC with http authentication and noticed this issue. 1620751 14 becky 2020-02-19 11:19:31 -0800 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. 1692653 15 james.x.anderson+bugzilla 2020-09-28 13:23:35 -0700 Still causing an issue with code that works just fine in Chrome (barring iOS Chrome which uses webkit) and Firefox 1701986 16 piota 2020-10-27 11:02:52 -0700 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 1873238 17 julian 2022-05-31 23:47:09 -0700 Is there any news on this 10 year old issue? Any explanation as to why you wouldn't want to support this? 2187035 18 bfulgham 2026-03-04 11:13:01 -0800 The fix for this should have shipped in Safari on macOS 12 (Monterey) and iOS 15.0 back in the fall of 2021. The fix was in system networking dependencies, so may not have been visible to downlevel Safari releases to older operating systems. Do you have a test case that shows the problem reproducing now in iOS 26/macOS 26? If so, please reopen this bug with further details. 2187109 19 andrewchen5678 2026-03-04 14:28:35 -0800 Just tested it and it is still not working on Safari only with MacOS 26 Tahoe. Can't believe this! 2187111 20 andrewchen5678 2026-03-04 14:31:37 -0800 Not working on iOS 26 either, please reopen! 2187163 21 ap 2026-03-04 16:41:05 -0800 Thank you for following up, reopening and creating a new internal copy. It would be helpful have a test case though, as there are many subtleties in authentication, and we may try to test a slightly different case than what you did. In particular, was it specifically ws://username:password, as mentioned in one of the comments? 2187164 22 webkit-bug-importer 2026-03-04 16:41:14 -0800 <rdar://problem/171761514> 2187165 23 andrewchen5678 2026-03-04 16:43:14 -0800 I used caddy to enforce sitewide http basic auth, which like always, all browsers like chrome, firefox, etc. works except safari