UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.183 Safari/537.36 Vivaldi/1.96.1147.42

Steps to reproduce the problem:
1. Attempt to override browser 'Accept' header
2. Chromium thinks I want 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8', 
   and damn what I tell it.

Additionally:

1. Try to set browser 'Referer' header
2. 'Referer' header is not sent.

This *sounds* like a reoccurance of https://bugs.chromium.org/p/chromium/issues/detail?id=767683
https://bugs.chromium.org/p/chromium/issues/detail?id=795336 
https://bugs.chromium.org/p/chromium/issues/detail?id=793031

But those issues are marked as "fix released" in chrome 64, and I'm on 67.

What is the expected behavior?
I expect the string I specify in setExtraHTTPHeaders to be sent verbatim in 
all cases when making network requests.

Note that this is the behaviour for *other* headers. I can specify garbage for 
things like the user-agent, and it will be sent without issue

This is particularly important if you're specifically trying to get the remote 
server to not send webp images, though the general case is important for my 
application (having chromium match a external header set *exactly*).

Additionally, being able to specify a referrer is somewhat critical in many cases.

What went wrong?
Someone is really excited about apng/webp, apparently, and decided 
that you are going to get them if you want it or not.

No idea why the referrer fails.

Did this work before? Yes somewhere around 61-65? I only wrote tests when I noticed it was broken.

Chrome version: 67.0.3396.62  Channel: n/a
OS Version: Ubuntu 18.04 server LTS
Flash Version: N/A

I have a script that exhibits this issue here:
https://github.com/fake-name/ChromeController/blob/master/tests/test_chromium.py

Clone the repo, and run `runTests.sh` from the repo root, and it pretty thoroughly 
exercises the setExtraHTTPHeaders interface (you will probably need to install a few 
packages). 

The script in this case are actually unit tests on the python wrapper I've written
for the chrome dev tools interface, but in this case the commands being sent to 
chrome are correct, and the responses are not.

The diagnostic output of my testing script is attached. It contains the complete
log of all the communications sent over the chrome remote debugging interface.

Note that the tests fail with `ChromeController.cr_exceptions.ChromeNavigateTimedOut: Blocking navigate timed out!`
because the testing server the unit-test spins up aborts when a unittest.TestCase 
assertion fails.
Propagating the failure to the main thread in a more clean way would be nice at some point.
 

Deleted: crome_fails.txt 182 KB

crome_fails.txt 182 KB View Download