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

net/http/http_network_transaction.cc

Index: net/http/http_network_transaction.cc
diff --git a/net/http/http_network_transaction.cc b/net/http/http_network_transaction.cc
index f4df073b4bba5ad905631653d2cba46820c0daa7..8ee9069c5574f0340a9cb3a6b0dd375ece30ded6 100644
--- a/net/http/http_network_transaction.cc
+++ b/net/http/http_network_transaction.cc
@@ -61,6 +61,7 @@
 #include "net/ssl/ssl_cert_request_info.h"
 #include "net/ssl/ssl_connection_status_flags.h"
 #include "url/gurl.h"
+#include "url/url_canon.h"
 
 #if defined(SPDY_PROXY_AUTH_ORIGIN)
 #include <algorithm>
@@ -1545,6 +1546,17 @@ GURL HttpNetworkTransaction::AuthURL(HttpAuth::Target target) const {
                   proxy_info_.proxy_server().host_port_pair().ToString());
     }
     case HttpAuth::AUTH_SERVER:
+      if (ForWebSocketHandshake()) {
+        const GURL& url = request_->url;
+        url::Replacements<char> ws_to_http;
+        if (url.SchemeIs("ws")) {
+          ws_to_http.SetScheme("http", url::Component(0, 4));
+        } else {
+          DCHECK(url.SchemeIs("wss"));
+          ws_to_http.SetScheme("https", url::Component(0, 5));
+        }
+        return url.ReplaceComponents(ws_to_http);
+      }

[Ryan Sleevi, 2014/07/29 19:54:32]

This seems like a violation of SOP.

ws://foo.bar != SOP as http://foo.bar

Is sharing credentials really correct here? I can't help but feel like, no, it's
not and shouldn't be.

[tyoshino (SeeGerritForStatus), 2014/07/30 03:39:54]

The default port is the same as HTTP for both secure and insecure. So the
request goes to the same TCP endpoint as one initiated for a URL with http
scheme. The server may differentiate incoming connection based on upgrade and
dispatches to different backends, but WebSocket was originally specified to be
able to share credentials with HTTP e.g. cookie, or other authentication info.
See the step 12 in http://tools.ietf.org/html/rfc6455#section-4.1. So, it's
server implementor or service developer's duty to take into account that
credentials stored for HTTP requests may be sent together with ws:// handshake.
It's bad that the step 12 doesn't introduce any algorithm like this to make the
authentication system work as the spec intended, but I believe this is ok.

[Adam Rice, 2014/07/30 03:43:34]

The issue is ws: both is and isn't the same protocol as http:. The same thing
applies for cookies; quoting the WhatWG WebSocket API 'The headers to send
appropriate cookies must be a Cookie header whose value is the cookie-string
computed from the user's cookie store and the URL url; for these purposes this
is not a "non-HTTP" API.'

The cookie behaviour has been long standardised and works without any
WebSocket-specific hacks because Chrome's cookie store doesn't really know about
URL schemes.

Authentication behaviour is not really standardised anywhere; RFC6455 mentions
it in passing, and the WhatWG standard effectively disallows it by banning
handling of status codes other than 101.

However, not implementing authentication leaves us incompatible with Firefox and
IE and means that a number of Intranet applications don't work with Chrome,
blocking Chrome adoption. Since we never popup UI for a WebSocket connection,
inheriting credentials from HTTP is the only reasonable implementation and is
also what Firefox and IE do.

My way of looking at it is that ws://foo.bar is "mostly" SOP as http://foo.bar.
They share cookies, credentials, client certificates, SSL exceptions, etc.

Another view some people take is that ws: is not a "real" URL scheme at all.

       return request_->url;
     default:
      return GURL();