Introduce RequestWebSocketStream into HttpStreamFactory

net/socket/client_socket_pool_manager.cc

Index: net/socket/client_socket_pool_manager.cc
diff --git a/net/socket/client_socket_pool_manager.cc b/net/socket/client_socket_pool_manager.cc
index cd4f10f374d6a0019130dc7297a2a1349393fdf4..c4449c64590ca66a468913ecd39742fb658dc95b 100644
--- a/net/socket/client_socket_pool_manager.cc
+++ b/net/socket/client_socket_pool_manager.cc
@@ -88,7 +88,8 @@ int InitSocketPoolHelper(const GURL& request_url,
   scoped_refptr<SOCKSSocketParams> socks_params;
   scoped_ptr<HostPortPair> proxy_host_port;
 
-  bool using_ssl = request_url.SchemeIs("https") || force_spdy_over_ssl;
+  bool using_ssl = request_url.SchemeIs("https") ||
+      request_url.SchemeIs("wss") || force_spdy_over_ssl;

[mmenke, 2013/05/28 21:22:37]

Another issue for the CL to use the right HttpStreamFactory:  If we're using an
HTTP proxy, we want to make sure we use it as a Connect proxy.  I believe the
current code will just connect to the HTTP proxy, and pass that on to the
WebSocketStream.

[yhirano, 2013/05/30 04:44:32]

I'm not sure if I understand your comment correctly, but we use CONNECT when we
use a proxy server, as RFC6455 says in 4.1, _Proxy Usage_
(http://tools.ietf.org/html/rfc6455#section-4.1). Is that resolve the problem?

[mmenke, 2013/05/30 19:27:12]

The issue is this code isn't using a CONNECT.  Look at
HttpProxyConnectJob::DoHttpProxyConnect and HttpProxyClientSocket::Connect. 
using_spdy_ will be false, as will params_->tunnel().  As a result, I believe
this code won't issue a CONNECT request.  Instead, it will determine a tunnel is
not in use, and HttpProxyClientSocket::Connect will complete synchronously,
without establishing the tunnel.

[yhirano, 2013/05/31 08:36:45]

I see, I added InitSocketHandleForWebSocket which calls the helper function with
force_tunnel = true in client_socket_pool_manager.h and use it if for_websocket_
is true.

 
   HostPortPair origin_host_port =
       HostPortPair(request_url.HostNoBrackets(),