https://chromium-review.googlesource.com/c/chromium/src/+/979746 contains a repro which you can checkout locally to test this. The repro uses a WebSocket as a convenient way to read the request header, but the issue is not limited to WebSockets.

net::URLRequestContextBuilder::enable_brotli_ is false by default but mojom::NetworkContextParams::enable_brotli is true by default.

ccing mmenke@, author of http://crrev.com/7d4b66f7910620c157848fa9ee762c393de18a5c

Why does enabling brotli cause a websocket test to fail?

I do think we want brotli enabled in content shell (Whether it's by default or done explicitly) - this better reflects what Chrome does, and brotli is a web standard.

#5 The output of the test includes the request headers. The expected file tells the story: https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/http/tests/devtools/websocket/websocket-handshake-expected.txt. This is all kinds of inconvenient, and it's not clear why we need a WebSocket test that does this when there isn't an HTTP test doing the same thing.

However, I won't advocate for removing a working test. My preference would be to make Brotli default to true in all configurations. Chrome's feature flag can still be used to disable it if needed.

Do we run layout tests in environments other than content_shell?  Just wondering if it's enough to update the test, or if other embedders need to be changed.

#7 Clusterfuzz runs them under the full browser. AFAIK that's all.

Edit: also Clusterfuzz doesn't know or care whether they match the expectations.

Great, I'll update the test expectations.

(And enable brotli in ContentShell with the network service turned off, of course)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1503cea47cd162eb6741162b900f710ab290878e

commit 1503cea47cd162eb6741162b900f710ab290878e
Author: Matt Menke <mmenke@chromium.org>
Date: Mon Apr 09 17:39:00 2018

Make websocket-handshake.js not depend on the Accept-Encoding header.

Also enable the test when the network service is enabled.

Content Shell sends a different content-encoding with the network
service enabled and disabled, due to Brotli only being enabled on one
path.  While I plan to enable Brotli in both cases, it also seems like
a good idea to remove this dependency.

Bug:  825687 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: I9c768099dfd6a876f7650088118de4582ec1ca46
Reviewed-on: https://chromium-review.googlesource.com/998756
Reviewed-by: Adam Rice <ricea@chromium.org>
Commit-Queue: Matt Menke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549214}
[modify] https://crrev.com/1503cea47cd162eb6741162b900f710ab290878e/third_party/WebKit/LayoutTests/FlagExpectations/enable-features=NetworkService
[modify] https://crrev.com/1503cea47cd162eb6741162b900f710ab290878e/third_party/WebKit/LayoutTests/http/tests/devtools/websocket/websocket-handshake-expected.txt
[modify] https://crrev.com/1503cea47cd162eb6741162b900f710ab290878e/third_party/WebKit/LayoutTests/http/tests/devtools/websocket/websocket-handshake.js

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/68c96cd827299807688dfd64e03a33deef06b69b

commit 68c96cd827299807688dfd64e03a33deef06b69b
Author: Matt Menke <mmenke@chromium.org>
Date: Wed Apr 18 16:33:45 2018

Enable Brotli in content_shell.

It already has Brotli enabled when using the network service, so this
makes behavior the same whether the network service is enabled or not.
Enabling makes more sense than disabling, since this matches Chrome's
behavior, and it's a web standard.

Bug:  825687 
Change-Id: Ifa45aa704df5e3948e27cf2f1b23f8f06764425f
Reviewed-on: https://chromium-review.googlesource.com/1015555
Commit-Queue: Matt Menke <mmenke@chromium.org>
Reviewed-by: Peter Beverloo <peter@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551712}
[modify] https://crrev.com/68c96cd827299807688dfd64e03a33deef06b69b/content/shell/browser/shell_url_request_context_getter.cc