[Devtools] Allow User-Agent header override for Websockets

[Devtools] Allow User-Agent header override for Websockets

This Should make it so a user can override Websockets through devtools
protocol.

BUG=446909
Committed: https://crrev.com/8031445e44e495dfdcc8011f05323a9e479596c7
Committed: https://crrev.com/cef397d06a9527ee4a3895572d448ba1e9377ca0
Cr-Original-Commit-Position: refs/heads/master@{#402627}
Cr-Commit-Position: refs/heads/master@{#402862}

[allada, 2016-05-24 01:10:41]

allada@chromium.org changed reviewers:
+ dgozman@chromium.org

[allada, 2016-05-24 01:10:41]

PTL (just checking to see if this is a good way for now)

[dgozman, 2016-05-24 19:02:31]

https://codereview.chromium.org/2003253002/diff/1/content/browser/renderer_ho...
File content/browser/renderer_host/websocket_host.cc (right):

https://codereview.chromium.org/2003253002/diff/1/content/browser/renderer_ho...
content/browser/renderer_host/websocket_host.cc:444: std::string user_agent =
agent->GetUserAgentOverride();
I'd reverse this dependency, reaching from NetworkHandler::SetUserAgentOverride
into WebSocketHost (or WebSocketDispatcherHost).

[allada, 2016-05-26 20:46:56]

Patchset #2 (id:20001) has been deleted

[allada, 2016-05-26 20:53:42]

Patchset #2 (id:40001) has been deleted

[allada, 2016-05-26 21:21:50]

Patchset #2 (id:60001) has been deleted

[allada, 2016-05-26 21:22:07]

allada@chromium.org changed reviewers:
+ caseq@chromium.org

[allada, 2016-05-26 21:22:08]

PTL

[dgozman, 2016-05-26 23:13:11]

This looks good from devtools side. We need a test though. Let's ask for review
from websocket owners.

[allada, 2016-05-27 21:26:27]

Patchset #3 (id:100001) has been deleted

[allada, 2016-05-27 21:29:33]

allada@chromium.org changed reviewers:
+ yhirano@chromium.org

[allada, 2016-05-27 21:29:34]

PTL

[yhirano, 2016-05-30 11:12:57]

Can you add a unit test in websocket_stream_test.cc for non-empty additional
headers?

https://codereview.chromium.org/2003253002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/websockets/DocumentWebSocketChannel.h
(right):

https://codereview.chromium.org/2003253002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/websockets/DocumentWebSocketChannel.h:134:
const WebString additionalHeaders();
|const| not needed?

https://codereview.chromium.org/2003253002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/websockets/DocumentWebSocketChannel.h:134:
const WebString additionalHeaders();
Can you tell me why you use WebString instead of String?

https://codereview.chromium.org/2003253002/diff/120001/third_party/WebKit/pub...
File third_party/WebKit/public/platform/modules/websockets/WebSocketHandle.h
(right):

https://codereview.chromium.org/2003253002/diff/120001/third_party/WebKit/pub...
third_party/WebKit/public/platform/modules/websockets/WebSocketHandle.h:60:
virtual void connect(const WebURL&, const WebVector<WebString>& protocols, const
WebSecurityOrigin&, const WebString&, WebSocketHandleClient*) = 0;
please add the param name.

[allada, 2016-05-31 20:55:14]

Patchset #4 (id:140001) has been deleted

[allada, 2016-06-01 18:29:35]

Patchset #4 (id:160001) has been deleted

[allada, 2016-06-01 18:33:41]

Patchset #4 (id:180001) has been deleted

[allada, 2016-06-01 19:06:41]

I made the requested changes PTL.

https://codereview.chromium.org/2003253002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/websockets/DocumentWebSocketChannel.h
(right):

https://codereview.chromium.org/2003253002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/websockets/DocumentWebSocketChannel.h:134:
const WebString additionalHeaders();
On 2016/05/30 11:12:57, yhirano wrote:
> |const| not needed?

Done.

https://codereview.chromium.org/2003253002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/websockets/DocumentWebSocketChannel.h:134:
const WebString additionalHeaders();
On 2016/05/30 11:12:57, yhirano wrote:
> Can you tell me why you use WebString instead of String?

Done.

https://codereview.chromium.org/2003253002/diff/120001/third_party/WebKit/pub...
File third_party/WebKit/public/platform/modules/websockets/WebSocketHandle.h
(right):

https://codereview.chromium.org/2003253002/diff/120001/third_party/WebKit/pub...
third_party/WebKit/public/platform/modules/websockets/WebSocketHandle.h:60:
virtual void connect(const WebURL&, const WebVector<WebString>& protocols, const
WebSecurityOrigin&, const WebString&, WebSocketHandleClient*) = 0;
On 2016/05/30 11:12:57, yhirano wrote:
> please add the param name.

Done.

[allada, 2016-06-01 19:12:36]

The CQ bit was checked by allada@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-01 19:13:04]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2003253002/200001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2003253002/200001

[commit-bot: I haz the power, 2016-06-01 19:28:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-01 19:28:58]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[dgozman, 2016-06-01 19:48:54]

devtools lgtm

https://codereview.chromium.org/2003253002/diff/200001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/http/tests/inspector-protocol/websocket/websocket-user-agent-override.html
(right):

https://codereview.chromium.org/2003253002/diff/200001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/inspector-protocol/websocket/websocket-user-agent-override.html:12:
testRunner.dumpAsText();
Harness does this for you. Remove.

[allada, 2016-06-01 20:34:03]

Patchset #5 (id:220001) has been deleted

[allada, 2016-06-01 20:34:20]

The CQ bit was checked by allada@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-01 20:34:59]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2003253002/240001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2003253002/240001

[commit-bot: I haz the power, 2016-06-02 03:16:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-02 03:16:38]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[yhirano, 2016-06-02 06:29:13]

https://codereview.chromium.org/2003253002/diff/240001/net/websockets/websock...
File net/websockets/websocket_stream_test.cc (right):

https://codereview.chromium.org/2003253002/diff/240001/net/websockets/websock...
net/websockets/websocket_stream_test.cc:384: TEST_F(WebSocketStreamCreateTest,
HandshakeOverrideHeaders) {
Can you add "additional_headers" parameter to WebSocketStandardRequest
[WithCookies] functions defined in websocket_test_util.cc? They will be used as
the default expectation and you will be able to write this test as same as
"OriginIsUsed" case.

[allada, 2016-06-02 23:35:17]

allada@chromium.org changed reviewers:
- caseq@chromium.org, dgozman@chromium.org

[allada, 2016-06-02 23:35:18]

PTL

https://codereview.chromium.org/2003253002/diff/200001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/http/tests/inspector-protocol/websocket/websocket-user-agent-override.html
(right):

https://codereview.chromium.org/2003253002/diff/200001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/inspector-protocol/websocket/websocket-user-agent-override.html:12:
testRunner.dumpAsText();
On 2016/06/01 19:48:54, dgozman wrote:
> Harness does this for you. Remove.

Done.

https://codereview.chromium.org/2003253002/diff/240001/net/websockets/websock...
File net/websockets/websocket_stream_test.cc (right):

https://codereview.chromium.org/2003253002/diff/240001/net/websockets/websock...
net/websockets/websocket_stream_test.cc:384: TEST_F(WebSocketStreamCreateTest,
HandshakeOverrideHeaders) {
On 2016/06/02 06:29:12, yhirano wrote:
> Can you add "additional_headers" parameter to WebSocketStandardRequest
> [WithCookies] functions defined in websocket_test_util.cc? They will be used
as
> the default expectation and you will be able to write this test as same as
> "OriginIsUsed" case.

Done. The reason there are two "additional_header" type fields is because one
pipes it all the way through for custom headers (my change) and the other is
there more to ensure certain headers are sent for certain conditions (like
ensuring Sec-WebSocket-Protocol header is sent when sub-protocol is set).

[allada, 2016-06-02 23:36:24]

The CQ bit was checked by allada@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-02 23:37:16]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2003253002/260001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2003253002/260001

[yhirano, 2016-06-03 02:15:09]

lgtm

[commit-bot: I haz the power, 2016-06-03 02:43:28]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-03 02:43:29]

Dry run: This issue passed the CQ dry run.

[allada, 2016-06-03 17:45:05]

The CQ bit was checked by allada@chromium.org

[allada, 2016-06-03 17:45:06]

The patchset sent to the CQ was uploaded after l-g-t-m from dgozman@chromium.org
Link to the patchset: https://codereview.chromium.org/2003253002/#ps260001
(title: " ")

[commit-bot: I haz the power, 2016-06-03 17:45:53]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2003253002/260001

[commit-bot: I haz the power, 2016-06-03 17:54:20]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-03 17:54:22]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Allada-Google, 2016-06-03 18:01:07]

allada@google.com changed reviewers:
+ allada@google.com, dgozman@chromium.org, tsepez@chromium.org

[Allada-Google, 2016-06-03 18:01:08]

PTL @ content/common/websocket_messages.h

[allada, 2016-06-03 18:02:30]

Description was changed from

==========
[Devtools] Allow User-Agent header override for Websockets

This Should make it so a user can override Websockets through devtools
protocol.

BUG=446909
==========

to

==========
[Devtools] Allow User-Agent header override for Websockets

This Should make it so a user can override Websockets through devtools
protocol.

BUG=446909
==========

[allada, 2016-06-03 18:02:30]

allada@chromium.org changed reviewers:
- allada@google.com

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

https://codereview.chromium.org/2003253002/diff/260001/content/common/websock...
File content/common/websocket_messages.h (right):

https://codereview.chromium.org/2003253002/diff/260001/content/common/websock...
content/common/websocket_messages.h:74: std::string /* additional_headers */,
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:58]

PTL @ Tom Sepez

https://codereview.chromium.org/2003253002/diff/260001/content/common/websock...
File content/common/websocket_messages.h (right):

https://codereview.chromium.org/2003253002/diff/260001/content/common/websock...
content/common/websocket_messages.h:74: std::string /* additional_headers */,
On 2016/06/03 18:08:40, Tom Sepez wrote:
> 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?

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?)

[Tom Sepez, 2016-06-06 16:08:24]

tsepez@chromium.org changed reviewers:
+ creis@chromium.org

[Tom Sepez, 2016-06-06 16:10:25]

> 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?)

+creis

The answer depends on how this affect a post site-isolation world, where each
origin is confined to its own process.  Would a compromised rendered be able to
get cross-origin info it's not entitled to by crafting an arbitrary outgoing
header (not just U-A) as your proposal would allow?

[Charlie Reis, 2016-06-06 23:34:39]

On 2016/06/06 16:10:25, Tom Sepez wrote:
> > 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?)
> 
> +creis
> 
> The answer depends on how this affect a post site-isolation world, where each
> origin is confined to its own process.  Would a compromised rendered be able
to
> get cross-origin info it's not entitled to by crafting an arbitrary outgoing
> header (not just U-A) as your proposal would allow?

Yes, it seems like it would be able to pass an arbitrary Origin header claiming
to be an origin that isn't allowed to commit in this process.  We have a limited
ability to catch that in the browser process and kill the renderer, but this
sounds like it might risk bypassing that.  I would be concerned not just about
Site Isolation but about web sites claiming to be apps, etc.  I'm not super
familiar with this code, but restricting this message seems like a good idea if
possible.

[Tom Sepez, 2016-06-07 15:49:58]

> Yes, it seems like it would be able to pass an arbitrary Origin header
claiming
> to be an origin that isn't allowed to commit in this process.  We have a
limited
> ability to catch that in the browser process and kill the renderer, but this
> sounds like it might risk bypassing that.  I would be concerned not just about
> Site Isolation but about web sites claiming to be apps, etc.  I'm not super
> familiar with this code, but restricting this message seems like a good idea
if
> possible.
So based upon that, I'm going to have to say not lgtm until we come up with a
less vulnerable design.

[pfeldman, 2016-06-08 00:11:38]

pfeldman@chromium.org changed reviewers:
+ pfeldman@chromium.org

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

https://codereview.chromium.org/2003253002/diff/260001/content/common/websock...
File content/common/websocket_messages.h (right):

https://codereview.chromium.org/2003253002/diff/260001/content/common/websock...
content/common/websocket_messages.h:73: url::Origin /* origin */,
@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...

[Tom Sepez, 2016-06-08 16:44:19]

On 2016/06/08 00:11:39, pfeldman wrote:
>
https://codereview.chromium.org/2003253002/diff/260001/content/common/websock...
> File content/common/websocket_messages.h (right):
> 
>
https://codereview.chromium.org/2003253002/diff/260001/content/common/websock...
> content/common/websocket_messages.h:73: url::Origin /* origin */,
> @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...

Yes, a design where only the value part of a user-agent header comes from the
renderer and is concatenated with the "user-agent: " part on the browser side is
fine.

[Tom Sepez, 2016-06-08 16:46:14]

> Yes, a design where only the value part of a user-agent header comes from the
> renderer and is concatenated with the "user-agent: " part on the browser side
is
> fine.
Of course, you'll need to validate browser-side that the value doesn't contain
newlines, etc or other punctuation that could be misinterpreted to introduce
another header.

[allada, 2016-06-21 01:33:21]

Patchset #7 (id:280001) has been deleted

[allada, 2016-06-21 01:33:31]

Patchset #7 (id:300001) has been deleted

[allada, 2016-06-21 01:33:40]

Patchset #7 (id:320001) has been deleted

[allada, 2016-06-21 01:33:56]

Patchset #7 (id:340001) has been deleted

[allada, 2016-06-21 01:39:05]

allada@chromium.org changed reviewers:
+ isherman@chromium.org

[allada, 2016-06-21 01:39:06]

PTL

After speaking to pfeldman@ he suggested that I only pass user-agent-override
then have browser combine it into additional_headers then pass
additional_headers to netstack.

[allada, 2016-06-21 01:46:17]

The CQ bit was checked by allada@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-21 01:46:55]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2003253002/360001

[commit-bot: I haz the power, 2016-06-21 03:14:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-21 03:14:34]

Dry run: This issue passed the CQ dry run.

[dgozman, 2016-06-21 17:32:48]

https://codereview.chromium.org/2003253002/diff/360001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/http/tests/inspector-protocol/websocket/websocket-user-agent-override.html
(right):

https://codereview.chromium.org/2003253002/diff/360001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/inspector-protocol/websocket/websocket-user-agent-override.html:7:
function openWebSocket(url) {
style: { on the new line

https://codereview.chromium.org/2003253002/diff/360001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/inspector-protocol/websocket/websocket-user-agent-override.html:11:
function test() {
ditto

[allada, 2016-06-21 17:40:28]

https://codereview.chromium.org/2003253002/diff/360001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/http/tests/inspector-protocol/websocket/websocket-user-agent-override.html
(right):

https://codereview.chromium.org/2003253002/diff/360001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/inspector-protocol/websocket/websocket-user-agent-override.html:7:
function openWebSocket(url) {
On 2016/06/21 17:32:48, dgozman wrote:
> style: { on the new line

Done.

https://codereview.chromium.org/2003253002/diff/360001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/http/tests/inspector-protocol/websocket/websocket-user-agent-override.html:11:
function test() {
On 2016/06/21 17:32:48, dgozman wrote:
> ditto

Done.

[Charlie Reis, 2016-06-21 18:49:52]

On 2016/06/21 01:39:06, Blaise wrote:
> PTL
> 
> After speaking to pfeldman@ he suggested that I only pass user-agent-override
> then have browser combine it into additional_headers then pass
> additional_headers to netstack.

That sounds like a better approach to me, thanks.  I'll let Tom confirm the
implementation change.

[Tom Sepez, 2016-06-26 15:34:05]

I think this is OK now, LGTM.

[allada, 2016-06-27 17:41:11]

The CQ bit was checked by allada@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-27 17:42:14]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-27 17:46:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-27 17:46:04]

Dry run: Try jobs failed on following builders:
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  ios-simulator-gn on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-gn/...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[allada, 2016-06-27 19:54:53]

The CQ bit was checked by allada@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-27 19:55:23]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-27 21:46:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-27 21:46:19]

Dry run: This issue passed the CQ dry run.

[allada, 2016-06-27 22:49:15]

The CQ bit was checked by allada@chromium.org

[allada, 2016-06-27 22:49:16]

The patchset sent to the CQ was uploaded after l-g-t-m from
dgozman@chromium.org, yhirano@chromium.org, tsepez@chromium.org
Link to the patchset: https://codereview.chromium.org/2003253002/#ps400001
(title: "tests")

[commit-bot: I haz the power, 2016-06-27 22:50:14]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-27 23:03:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-27 23:03:56]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[allada, 2016-06-27 23:33:33]

allada@chromium.org changed reviewers:
+ holte@chromium.org

[allada, 2016-06-27 23:33:34]

PTL

[Charlie Reis, 2016-06-27 23:43:40]

On 2016/06/27 23:33:34, Blaise wrote:
> PTL

Who are you asking to look?

[allada, 2016-06-28 00:36:26]

On 2016/06/27 23:43:40, Charlie Reis wrote:
> On 2016/06/27 23:33:34, Blaise wrote:
> > PTL
> 
> Who are you asking to look?

Sorry, I thought I did a review without email. It is for holte@

[Ilya Sherman, 2016-06-28 03:12:16]

histograms.xml lgtm

[allada, 2016-06-28 18:44:53]

The CQ bit was checked by allada@chromium.org

[commit-bot: I haz the power, 2016-06-28 18:46:03]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-28 18:55:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-28 18:55:17]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Charlie Reis, 2016-06-28 21:43:07]

content/browser/bad_message.h (and the BadMessageReceived call) LGTM.  (I
haven't looked closely at the rest, but it looks like you have sufficient owner
approval otherwise.)

[allada, 2016-06-28 22:42:44]

The CQ bit was checked by allada@chromium.org

[commit-bot: I haz the power, 2016-06-28 22:43:57]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-29 01:00:13]

Description was changed from

==========
[Devtools] Allow User-Agent header override for Websockets

This Should make it so a user can override Websockets through devtools
protocol.

BUG=446909
==========

to

==========
[Devtools] Allow User-Agent header override for Websockets

This Should make it so a user can override Websockets through devtools
protocol.

BUG=446909
==========

[commit-bot: I haz the power, 2016-06-29 01:00:16]

Committed patchset #9 (id:400001)

[commit-bot: I haz the power, 2016-06-29 01:02:01]

Description was changed from

==========
[Devtools] Allow User-Agent header override for Websockets

This Should make it so a user can override Websockets through devtools
protocol.

BUG=446909
==========

to

==========
[Devtools] Allow User-Agent header override for Websockets

This Should make it so a user can override Websockets through devtools
protocol.

BUG=446909

Committed: https://crrev.com/8031445e44e495dfdcc8011f05323a9e479596c7
Cr-Commit-Position: refs/heads/master@{#402627}
==========

[commit-bot: I haz the power, 2016-06-29 01:02:04]

Patchset 9 (id:??) landed as
https://crrev.com/8031445e44e495dfdcc8011f05323a9e479596c7
Cr-Commit-Position: refs/heads/master@{#402627}

[allada, 2016-06-29 17:27:00]

Description was changed from

==========
[Devtools] Allow User-Agent header override for Websockets

This Should make it so a user can override Websockets through devtools
protocol.

BUG=446909

Committed: https://crrev.com/8031445e44e495dfdcc8011f05323a9e479596c7
Cr-Commit-Position: refs/heads/master@{#402627}
==========

to

==========
[Devtools] Allow User-Agent header override for Websockets

This Should make it so a user can override Websockets through devtools
protocol.

BUG=446909

Committed: https://crrev.com/8031445e44e495dfdcc8011f05323a9e479596c7
Cr-Commit-Position: refs/heads/master@{#402627}
==========

[allada, 2016-06-29 17:29:15]

The revert to this patch was not relevant to the tests that were failing. In
relation to conversations with penghuang@ and lushnikov@. Therefore I am going
to re-commit this patch.

[allada, 2016-06-29 17:29:36]

The CQ bit was checked by allada@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-29 17:30:35]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-29 17:40:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-29 17:40:57]

Dry run: This issue passed the CQ dry run.

[Allada-Google, 2016-06-29 17:42:20]

The CQ bit was checked by allada@google.com

[commit-bot: I haz the power, 2016-06-29 17:43:44]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-29 17:52:39]

Description was changed from

==========
[Devtools] Allow User-Agent header override for Websockets

This Should make it so a user can override Websockets through devtools
protocol.

BUG=446909

Committed: https://crrev.com/8031445e44e495dfdcc8011f05323a9e479596c7
Cr-Commit-Position: refs/heads/master@{#402627}
==========

to

==========
[Devtools] Allow User-Agent header override for Websockets

This Should make it so a user can override Websockets through devtools
protocol.

BUG=446909

Committed: https://crrev.com/8031445e44e495dfdcc8011f05323a9e479596c7
Cr-Commit-Position: refs/heads/master@{#402627}
==========

[commit-bot: I haz the power, 2016-06-29 17:52:42]

Committed patchset #9 (id:400001)

[commit-bot: I haz the power, 2016-06-29 17:52:50]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-06-29 17:54:24]

Description was changed from

==========
[Devtools] Allow User-Agent header override for Websockets

This Should make it so a user can override Websockets through devtools
protocol.

BUG=446909

Committed: https://crrev.com/8031445e44e495dfdcc8011f05323a9e479596c7
Cr-Commit-Position: refs/heads/master@{#402627}
==========

to

==========
[Devtools] Allow User-Agent header override for Websockets

This Should make it so a user can override Websockets through devtools
protocol.

BUG=446909

Committed: https://crrev.com/8031445e44e495dfdcc8011f05323a9e479596c7
Committed: https://crrev.com/cef397d06a9527ee4a3895572d448ba1e9377ca0
Cr-Original-Commit-Position: refs/heads/master@{#402627}
Cr-Commit-Position: refs/heads/master@{#402862}
==========

[commit-bot: I haz the power, 2016-06-29 17:54:27]

Patchset 9 (id:??) landed as
https://crrev.com/cef397d06a9527ee4a3895572d448ba1e9377ca0
Cr-Commit-Position: refs/heads/master@{#402862}