I filed a bug (b/36860275) on the server for leaking these headers in the general case of actually using data saver for the request. For your specific repro, was the page served over data saver or was it served direct (buddy.jpg vs grumpycat.jpg).

I'd be interested if there is strange redirect/cache behavior going on. I could not repro this while data saver was bypassed. (no Chrome-Proxy-* headers were present).

I had recently added DCHECKs to capture this: https://cs.chromium.org/chromium/src/components/data_reduction_proxy/core/browser/data_reduction_proxy_network_delegate.cc?q=f:data_reduction_proxy+f:network+package:%5Echromium$&dr&l=121

Obviously, those DCHECKs won't trigger in release builds.

ECT header used the same code path as CPAT, so it is hardly a surprise that the bug (if there is one) would affect both headers.

FWIW, I could not repro this with the test URLs in https://cs.chromium.org/chromium/src/tools/chrome_proxy/webdriver/bypass.py.

May be we should also run our integration tests against debug build of Chrome. That will make sure that we are not triggering any DCHECKs in the DRP code.

Re#1: Redirect restarts the network transaction, and that should cause the headers to be regenerated. I verified that this does not repro for redirect cases (e.g., navigate to http://nytimes.com  which redirects to HTTPS).

The page was served direct, and the request headers did not include a Via header, no X-Forwarded-For, etc.

I've gotten direct page several times now (with grumpycat) but haven't seen a repro of the headers issue. 

Btw, one reproducible way I get the direct main page is to first nav to http://check.googlezip.net/block/ and then nav to aws1.mdw.la/fw
(... but this path has not shown the ECT header for me).

Matt, please report if you get this to happen again. Seems to be a subtle issue (of course because we don't yet see it).

It looks like the server is no longer leaking proxy headers so it may be more obvious now when this issue occurs.

Feel free to re-open if the problem reappears.