[Devtools] Allow User-Agent header override for Websockets

content/common/websocket_messages.h

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // Multiply-included message file, hence no include guard.
 
 // This file defines the IPCs for the browser-side implementation of
 // WebSockets.
 //
 // This IPC interface was originally desined based on the WebSocket
@@ skipping 49 matching lines @@
   IPC_STRUCT_TRAITS_MEMBER(headers)
   IPC_STRUCT_TRAITS_MEMBER(headers_text)
   IPC_STRUCT_TRAITS_MEMBER(response_time)
 IPC_STRUCT_TRAITS_END()
 
 // WebSocket messages sent from the renderer to the browser.
 
 // Open new WebSocket connection to |socket_url|. |requested_protocols| is a
 // list of tokens identifying sub-protocols the renderer would like to use, as
 // described in RFC6455 "Subprotocols Using the WebSocket Protocol".
-IPC_MESSAGE_ROUTED4(WebSocketHostMsg_AddChannelRequest,
+IPC_MESSAGE_ROUTED5(WebSocketHostMsg_AddChannelRequest,
                     GURL /* socket_url */,
                     std::vector<std::string> /* requested_protocols */,
                     url::Origin /* origin */,

[pfeldman, 2016/06/08 00:11:39]

@tsepez, @creis: should we rename this origin into untrusted_origin or
something? because it gets plumbed into the network stack and it goes from the
renderer. Do you think we could pass user_agent_header only? That's the only one
we need and it seems fairly safe to override it by untrusted renderer - it can
do uglier things anyways...

+                    std::string /* additional_headers */,

[Tom Sepez, 2016/06/03 18:08:40]

Seems like a bad idea to let the renderer specificy arbitrary headers.
Can this be made into a flag indicating "add the expected extra headers for ws"?
How does the browser know that its one of the special devtools rendered
use-cases where this is allowed vs. an ordinary renderer?

[allada, 2016/06/03 23:48:57]

Right now it's not exposed to any script interfaces. Yes, we could have probably
passed a "use this User-Agent" string/flag, but this seems like it's a bit too
restrictive. Right now it's NetStack who chooses the useragent to use. For fetch
requests we allow additional headers to be passed along in an options struct. I
could have had the browser handle the passing of user-agent, but that also
seemed like the wrong thing to do, and we would have needed to hold a map in
Inspector to frames that need this override. I could have also created an
options struct to set this info up and pass it all the way to netstack, but that
seemed like overkill and right now we do not have any other params that need to
be passed to netstack other than user agent. We **MAY** use a custom header to
fix websocket throttling like Fetch does (but this solution would be a bandaid
and not a fix).

I would be ok with passing a header struct that only allow certain headers to
get to browser or netstack? (but would that be necessary?)

                     int /* render_frame_id */)
 
 // Send a complete binary WebSocket message consisting of the Blob identified by
 // |uuid|. The message will be split into frames as necessary. |expected_size|
 // must match the browser's idea of the size of the Blob to prevent flow control
 // from becoming desynchronised. If it does not match the connection will be
 // terminated with a WebSocketMsg_NotifyFailure message. On success, the browser
 // will have consumed |expected_size| bytes of flow control send quota and the
 // renderer needs to subtract that from its running total of flow control send
 // quota. See the design doc at
@@ skipping 102 matching lines @@
 //   a closing handshake and the renderer cannot accept any new messages on this
 //   connection.
 IPC_MESSAGE_ROUTED3(WebSocketMsg_DropChannel,
                     bool /* was_clean */,
                     unsigned short /* code */,
                     std::string /* reason */)
 
 // Notify the renderer that a closing handshake has been initiated by the
 // server, so that it can set the Javascript readyState to CLOSING.
 IPC_MESSAGE_ROUTED0(WebSocketMsg_NotifyClosing)