Re: Issue 123862 in chromium: WebSocket upgrade handshake does not handle HTTP status 401

[chro...@googlecode.com]

Updates:
Summary: WebSocket upgrade handshake does not handle HTTP status 401
Status: Assigned
Owner: ri...@chromium.org
Cc: -ba...@chromium.org -ri...@chromium.org
Labels: -OS-Windows

Comment #38 on issue 123862 by tyos...@chromium.org: WebSocket upgrade
handshake does not handle HTTP status 401
http://code.google.com/p/chromium/issues/detail?id=123862

(No comment was entered for this change.)

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #39 on issue 123862 by n...@petrovits.net: WebSocket upgrade

handshake does not handle HTTP status 401
http://code.google.com/p/chromium/issues/detail?id=123862

I can replicate the same issue on a new project we are developing as an
intranet web application. Our application is configured to use Windows
Authentication with Kerberos. We had to disable NTLM since our application
requires ticket delegation for impersonation and logging into other servers
Windows servers.

When Chrome attempts a WebSocket connection it fails with the following
error:
WebSocket connection
to 'ws://Application.IntranetDomain/signalr/connect?transport=webSockets&clientProtocol=1.4&connectionToken=TokenReplacedWithThisText%3D%3D&connectionData=%5B%7B%22name%22%3A%22signalrhubname%22%7D%5D&tid=7'
failed: Error during WebSocket handshake: Unexpected response code: 401
jquery.signalR-2.1.0.min.js

Using IE10 and IE11 we are able to establish WebSocket connections, but we
would prefer to deploy the application to our user base as a Chrome
Application. (using an icon launching Chrome with the -app parameter.)

Thankfully SignalR falls back to long polling and Chrome works OK with
Kerberos authentication.

Please let me know if I can provide any more data. I am willing to assist
testing a fix once support for authentication is added to Chrome WebSockets.

Thank you,
Nick

[chro...@googlecode.com]

Comment #40 on issue 123862 by bugdro...@chromium.org: WebSocket upgrade

handshake does not handle HTTP status 401

http://code.google.com/p/chromium/issues/detail?id=123862#c40

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/8d7ed25ca422433e8e4c23262fde158019d1d565

commit 8d7ed25ca422433e8e4c23262fde158019d1d565
Author: ri...@chromium.org
<ri...@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Thu Jul 10 11:13:47 2014

Map WebSocket URL schemes to HTTP URL schemes for auth purposes.

This permits WebSocket connections to inherit credentials from HTTP pages,
and
matches the behaviour of other browsers.

Design doc:
https://docs.google.com/a/chromium.org/document/d/129rLtf5x3hvhP5rayLiSxnEjOXS8Z7EnLJgBL4CdwjI/edit

Also consider any 401 or 407 results that reach the WebSocketStream
URLRequest::Delegate to be unrecoverable errors.

Also ensure that the response headers are reported back to the renderer
when the developer tools are open and a 401 error happens.

BUG=123862

Review URL: https://codereview.chromium.org/336263005

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@282307
0039d316-1c4b-4281-b951-d872f2087c98

[chro...@googlecode.com]

Comment #41 on issue 123862 by bugdro...@chromium.org: WebSocket upgrade

handshake does not handle HTTP status 401

http://code.google.com/p/chromium/issues/detail?id=123862#c41

------------------------------------------------------------------
r282307 | ri...@chromium.org | 2014-07-10T11:13:47.083971Z

Changed paths:
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/tools/testserver/testserver.py?r1=282307&r2=282306&pathrev=282307
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_basic_handshake_stream.cc?r1=282307&r2=282306&pathrev=282307
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/test/spawned_test_server/base_test_server.cc?r1=282307&r2=282306&pathrev=282307
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/test/spawned_test_server/base_test_server.h?r1=282307&r2=282306&pathrev=282307
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/data/websocket/README?r1=282307&r2=282306&pathrev=282307
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/websocket_browsertest.cc?r1=282307&r2=282306&pathrev=282307
A
http://src.chromium.org/viewvc/chrome/trunk/src/net/data/websocket/connect_to.html?r1=282307&r2=282306&pathrev=282307
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream_test.cc?r1=282307&r2=282306&pathrev=282307
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream.cc?r1=282307&r2=282306&pathrev=282307
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=282307&r2=282306&pathrev=282307
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream.h?r1=282307&r2=282306&pathrev=282307

Map WebSocket URL schemes to HTTP URL schemes for auth purposes.

This permits WebSocket connections to inherit credentials from HTTP pages,
and
matches the behaviour of other browsers.

Design doc:
https://docs.google.com/a/chromium.org/document/d/129rLtf5x3hvhP5rayLiSxnEjOXS8Z7EnLJgBL4CdwjI/edit

Also consider any 401 or 407 results that reach the WebSocketStream
URLRequest::Delegate to be unrecoverable errors.

Also ensure that the response headers are reported back to the renderer
when the developer tools are open and a 401 error happens.

BUG=123862

Review URL: https://codereview.chromium.org/336263005

-----------------------------------------------------------------

[chro...@googlecode.com]

Comment #42 on issue 123862 by bugdro...@chromium.org: WebSocket upgrade

handshake does not handle HTTP status 401

http://code.google.com/p/chromium/issues/detail?id=123862#c42

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/ebe843d5ced1ebe145bb8d86b3eabb6fe5437ecc

commit ebe843d5ced1ebe145bb8d86b3eabb6fe5437ecc
Author: kaliam...@chromium.org
<kaliam...@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Thu Jul 10 15:18:44 2014

Revert 282307 "Map WebSocket URL schemes to HTTP URL schemes for..."

> Map WebSocket URL schemes to HTTP URL schemes for auth purposes.

> This permits WebSocket connections to inherit credentials from HTTP
> pages, and
> matches the behaviour of other browsers.

> Design doc:
> https://docs.google.com/a/chromium.org/document/d/129rLtf5x3hvhP5rayLiSxnEjOXS8Z7EnLJgBL4CdwjI/edit

> Also consider any 401 or 407 results that reach the WebSocketStream
> URLRequest::Delegate to be unrecoverable errors.

> Also ensure that the response headers are reported back to the renderer
> when the developer tools are open and a 401 error happens.

> BUG=123862

> Review URL: https://codereview.chromium.org/336263005

Seems to cause WebSocket1 failure in WinXP

TBR=ri...@chromium.org

Review URL: https://codereview.chromium.org/388493002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@282331
0039d316-1c4b-4281-b951-d872f2087c98

[chro...@googlecode.com]

Comment #43 on issue 123862 by bugdro...@chromium.org: WebSocket upgrade

handshake does not handle HTTP status 401

http://code.google.com/p/chromium/issues/detail?id=123862#c43

------------------------------------------------------------------
r282331 | kaliam...@chromium.org | 2014-07-10T15:18:44.822782Z

Changed paths:
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/test/spawned_test_server/base_test_server.cc?r1=282331&r2=282330&pathrev=282331
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/test/spawned_test_server/base_test_server.h?r1=282331&r2=282330&pathrev=282331
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/data/websocket/README?r1=282331&r2=282330&pathrev=282331
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/websocket_browsertest.cc?r1=282331&r2=282330&pathrev=282331
D
http://src.chromium.org/viewvc/chrome/trunk/src/net/data/websocket/connect_to.html?r1=282331&r2=282330&pathrev=282331
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream_test.cc?r1=282331&r2=282330&pathrev=282331
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream.cc?r1=282331&r2=282330&pathrev=282331
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=282331&r2=282330&pathrev=282331
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream.h?r1=282331&r2=282330&pathrev=282331
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/tools/testserver/testserver.py?r1=282331&r2=282330&pathrev=282331
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_basic_handshake_stream.cc?r1=282331&r2=282330&pathrev=282331

Revert 282307 "Map WebSocket URL schemes to HTTP URL schemes for..."

> Map WebSocket URL schemes to HTTP URL schemes for auth purposes.

> This permits WebSocket connections to inherit credentials from HTTP
> pages, and
> matches the behaviour of other browsers.

> Design doc:
> https://docs.google.com/a/chromium.org/document/d/129rLtf5x3hvhP5rayLiSxnEjOXS8Z7EnLJgBL4CdwjI/edit

> Also consider any 401 or 407 results that reach the WebSocketStream
> URLRequest::Delegate to be unrecoverable errors.

> Also ensure that the response headers are reported back to the renderer
> when the developer tools are open and a 401 error happens.

> BUG=123862

> Review URL: https://codereview.chromium.org/336263005

Seems to cause WebSocket1 failure in WinXP

TBR=ri...@chromium.org

Review URL: https://codereview.chromium.org/388493002

-----------------------------------------------------------------

[chro...@googlecode.com]

Comment #44 on issue 123862 by bugdro...@chromium.org: WebSocket upgrade

handshake does not handle HTTP status 401

http://code.google.com/p/chromium/issues/detail?id=123862#c44

The following revision refers to this bug:

https://chromium.googlesource.com/chromium/src.git/+/e69c1cd33dee41835499a5130c3431a059b4ac7d

commit e69c1cd33dee41835499a5130c3431a059b4ac7d
Author: ri...@chromium.org
<ri...@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Tue Jul 29 07:42:29 2014

Map WebSocket URL schemes to HTTP URL schemes for auth purposes.

This permits WebSocket connections to inherit credentials from HTTP pages,
and
matches the behaviour of other browsers.

Design doc:
https://docs.google.com/a/chromium.org/document/d/129rLtf5x3hvhP5rayLiSxnEjOXS8Z7EnLJgBL4CdwjI/edit

Also consider any 401 or 407 results that reach the WebSocketStream
URLRequest::Delegate to be unrecoverable errors.

Also ensure that the response headers are reported back to the renderer
when the developer tools are open and a 401 error happens.

BUG=123862

Review URL: https://codereview.chromium.org/336263005

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@286108
0039d316-1c4b-4281-b951-d872f2087c98

[chro...@googlecode.com]

Comment #45 on issue 123862 by bugdro...@chromium.org: WebSocket upgrade

handshake does not handle HTTP status 401

http://code.google.com/p/chromium/issues/detail?id=123862#c45

------------------------------------------------------------------
r286108 | ri...@chromium.org | 2014-07-29T07:42:29.835274Z

Changed paths:
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/test/spawned_test_server/base_test_server.cc?r1=286108&r2=286107&pathrev=286108
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/test/spawned_test_server/base_test_server.h?r1=286108&r2=286107&pathrev=286108
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/data/websocket/README?r1=286108&r2=286107&pathrev=286108
M
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/websocket_browsertest.cc?r1=286108&r2=286107&pathrev=286108
A
http://src.chromium.org/viewvc/chrome/trunk/src/net/data/websocket/connect_to.html?r1=286108&r2=286107&pathrev=286108
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream_test.cc?r1=286108&r2=286107&pathrev=286108
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream.cc?r1=286108&r2=286107&pathrev=286108
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=286108&r2=286107&pathrev=286108
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_stream.h?r1=286108&r2=286107&pathrev=286108
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/tools/testserver/testserver.py?r1=286108&r2=286107&pathrev=286108
M
http://src.chromium.org/viewvc/chrome/trunk/src/net/websockets/websocket_basic_handshake_stream.cc?r1=286108&r2=286107&pathrev=286108

Map WebSocket URL schemes to HTTP URL schemes for auth purposes.

This permits WebSocket connections to inherit credentials from HTTP pages,
and
matches the behaviour of other browsers.

Design doc:
https://docs.google.com/a/chromium.org/document/d/129rLtf5x3hvhP5rayLiSxnEjOXS8Z7EnLJgBL4CdwjI/edit

Also consider any 401 or 407 results that reach the WebSocketStream
URLRequest::Delegate to be unrecoverable errors.

Also ensure that the response headers are reported back to the renderer
when the developer tools are open and a 401 error happens.

BUG=123862

Review URL: https://codereview.chromium.org/336263005

-----------------------------------------------------------------

[chro...@googlecode.com]

Comment #46 on issue 123862 by hup...@googlemail.com: WebSocket upgrade

handshake does not handle HTTP status 401
http://code.google.com/p/chromium/issues/detail?id=123862

I made a SignalR test with version 2.1.1. Bug is still there. Really
funny... Internet Explorer can handle it ;)

[chro...@googlecode.com]

Comment #47 on issue 123862 by rebel7...@gmail.com: WebSocket upgrade

handshake does not handle HTTP status 401
http://code.google.com/p/chromium/issues/detail?id=123862

When I submitted this issue 2 years and 4 months ago, Firefox was the only
browser that supported basic auth with websockets. Somewhere between then
and now, IE began supporting it as well. Now it is just Chrome that doesn't.

But I am thankful that someone is now finally trying to get this to work!

[chro...@googlecode.com]

Comment #49 on issue 123862 by ri...@chromium.org: WebSocket upgrade

handshake does not handle HTTP status 401

https://code.google.com/p/chromium/issues/detail?id=123862

myrddin, are you sure that the WebSocket is prompting for authentication?
It's not supposed to. It's supposed to inherit the authentication from
HTTP(S). The host and port must match, ie. wss://example.com:8443/ will
inherit authentication credentials from https://example.com:8443/ but not
from https://example.com/.

NTLM support is a known gap. It's scheduled for implementation, but I
cannot make any guarantees about when.

[chro...@googlecode.com]

Comment #51 on issue 123862 by n...@petrovits.net: WebSocket upgrade

handshake does not handle HTTP status 401
https://code.google.com/p/chromium/issues/detail?id=123862

I am not seeing this work with Negotiate in Chrome Version 38.0.2125.101.

IE11 is able to connect using web sockets, but Chrome is not.

Chrome still fails with the following error message:
WebSocket connection
to 'ws://signalr.[redacted]:8080/signalr/connect?transport=webSockets&clientProtocol=1.4&connectionToken=[redacted]&connectionData=%5B%7B%22name%22%3A%22[redacted]%22%7D%5D&tid=8'
failed: HTTP Authentication failed; no valid credentials available

The web url for the site is:
http://[redacted]:8080/

Note, that this is different then signalr.[redacted]:8080. The SignalR
endpoint has a unique dns name for performance. This way a socket isn't
used up if the client doesn't support web sockets. (As some browsers have a
very low socket limit per domain.)

[chro...@googlecode.com]

Comment #52 on issue 123862 by n...@petrovits.net: WebSocket upgrade

handshake does not handle HTTP status 401
https://code.google.com/p/chromium/issues/detail?id=123862

Extending on post #51...

I have confirmed that changing my SignalR Url will allow this to work with
the value:
'ws://[redacted]:8080/signalr'

Sadly, this is not a feasible production url for us, and it must be:
'ws://signalr.[redacted]:8080/signalr'

[chro...@googlecode.com]

Comment #53 on issue 123862 by AlexejLo...@gmail.com: WebSocket upgrade

handshake does not handle HTTP status 401
https://code.google.com/p/chromium/issues/detail?id=123862

Extending on post #52...

I am using the same url for both the web site and ws, but am still getting
the same issue with HTTP Authentication failed; no valid credentials.

[chro...@googlecode.com]

Comment #57 on issue 123862 by cynthia....@intel.com: WebSocket upgrade

handshake does not handle HTTP status 401
https://code.google.com/p/chromium/issues/detail?id=123862

Please Fix

[chro...@googlecode.com]

Comment #58 on issue 123862 by brianben...@gmail.com: WebSocket upgrade

handshake does not handle HTTP status 401
https://code.google.com/p/chromium/issues/detail?id=123862

Please fix this bug

[chro...@googlecode.com]

Comment #60 on issue 123862 by joeschmo...@gmail.com: WebSocket upgrade

handshake does not handle HTTP status 401
https://code.google.com/p/chromium/issues/detail?id=123862

Please fix

[chro...@googlecode.com]

Comment #62 on issue 123862 by alexande...@gmail.com: WebSocket upgrade

handshake does not handle HTTP status 401
https://code.google.com/p/chromium/issues/detail?id=123862

This is a very basic functionality that should work. It would be very much
appreciated if it can be resolved,

[chro...@googlecode.com]

Comment #64 on issue 123862 by oofim...@gmail.com: WebSocket upgrade

handshake does not handle HTTP status 401
https://code.google.com/p/chromium/issues/detail?id=123862

Please fix the reported bug!

[chro...@googlecode.com]

Updates:
Status: Fixed

Comment #65 on issue 123862 by ri...@chromium.org: WebSocket upgrade

handshake does not handle HTTP status 401
https://code.google.com/p/chromium/issues/detail?id=123862

Please do not make information-free comments such a "please fix". Specific
information such as products or services which are impacted, and number of
users affected are useful. Network logs of authentication failures as
described in http://dev.chromium.org/for-testers/providing-network-details
are very useful.

I am closing this issue as HTTP status 401 is now supported. I have created
a new issue for Windows authentication support: crbug.com/423609

[chro...@googlecode.com]

Comment #66 on issue 123862 by yhi...@chromium.org: WebSocket upgrade

handshake does not handle HTTP status 401
https://code.google.com/p/chromium/issues/detail?id=123862

Issue 433608 has been merged into this issue.

[chro...@googlecode.com]

Comment #67 on issue 123862 by rebel7...@gmail.com: WebSocket upgrade

handshake does not handle HTTP status 401
https://code.google.com/p/chromium/issues/detail?id=123862

For us non-developers, what (released) version of chrome has this fixed? As
the OP, I'd like to test this, but don't have the ability to build a
Windows version

[chro...@googlecode.com]

Comment #70 on issue 123862 by yong...@toremote.com: WebSocket upgrade

handshake does not handle HTTP status 401
https://code.google.com/p/chromium/issues/detail?id=123862

This still doesn't work if websocket server is behind VPN.
Tested on Dell Sonicwall virtual appliance.

Create a bookmark and enabled SSO (this will use HTTP Basic Auth).

The url for the browser

https://192.168.100.1/go/http://192.168.12.110/example12.html

(internal url is http://192.168.12.110/example12.html):

There are two problems on this:

1. When you create a websocket on this page
wss://192.168.100.1/go/http://192.168.12.110
The Authorization header is not set.

2. When the server return 401 during the WebSocekt handshake. There is no
credential dialog displayed as usual and websocket is simply closed.

This wouldn't happen if you access the internal web address.

Firefox also have issue 1, but credential dialog is displayed and
Authorization header will be set after.

You can download Sonicwall virtual appliance to test this.

http://support-public.cfm.software.dell.com/25879_sra_virtual_appliance_getting_started_guide.pdf

I believe this should happen on Cisco, Juniper and other VPN applicane too
because they use same kind of URL.





Attachments:
sonicwall.PNG 60.4 KB

[chro...@googlecode.com]

Comment #71 on issue 123862 by ri...@chromium.org: WebSocket upgrade

handshake does not handle HTTP status 401
https://code.google.com/p/chromium/issues/detail?id=123862

#70: It sounds like Chrome does not believe it has cached credentials
matching this connection. Chrome will never display an authentication
dialogue for a WebSocket connection.

It might be possible for me to diagnose further if you send me a network
log as described in
https://dev.chromium.org/for-testers/providing-network-details but it will
have to contain credential information which may not be desirable.

[chro...@googlecode.com]

Comment #72 on issue 123862 by yong...@toremote.com: WebSocket upgrade

handshake does not handle HTTP status 401
https://code.google.com/p/chromium/issues/detail?id=123862

The network log file was attached


Attachments:
net-internals-log.json 527 KB

[chro...@googlecode.com]

Comment #73 on issue 123862 by ri...@chromium.org: WebSocket upgrade

handshake does not handle HTTP status 401
https://code.google.com/p/chromium/issues/detail?id=123862

#72 yongtao: Sorry for the slow response.

This server appears to use cookie-based authentication for HTTPS requests
and only use HTTP Basic authentication for WSS requests. This won't work
with Chrome because it doesn't display authentication dialogues for
WebSocket connections. If the user hasn't already entered their credentials.

I'm not sure whether the VPN is making any difference. Perhaps the original
server always used Basic auth but the VPN translates it into cookie-based
auth for HTTPS, but not for WSS?

If that is the case, then the VPN needs to use the same authentication
method for both HTTPS and WSS.

You could open a new bug asking for authentication UI to be shown for
WebSocket requests, and our UI people would look at it, but the decision
not to popup a login/password box probably won't change.

[chro...@googlecode.com]

Comment #74 on issue 123862 by yong...@toremote.com: WebSocket upgrade

handshake does not handle HTTP status 401
https://code.google.com/p/chromium/issues/detail?id=123862

Thanks a lot for your response which is actually fast considering we are in
holiday season.

[chro...@googlecode.com]

Comment #75 on issue 123862 by ray.bellis: WebSocket upgrade handshake does

not handle HTTP status 401
https://code.google.com/p/chromium/issues/detail?id=123862

I'm having this same problem on Safari 9.0.3 (11601.4.4) although current
Chrome and Firefox work as expected. Has anyone else here seen problems
with Safari and perhaps knows of a ticket referring to it? I can't find
anything online.