Chrome Version       : 64.0.3282.167
OS Version: OS X 10.13.3

What steps will reproduce the problem?
1. Write a Chrome extension using the webRequest.onHeadersRecieved API
2. Attempt to modify the 'status' header exposed by the API to, e.g. 500.

What is the expected result?

That the browser (including devtools network monitor) behave as if the server responded with a 500. 

What happens instead of that?

The status line remains unchanged.


Please provide any additional information below. Attach a screenshot if
possible.

I'm filing this bug at the request of rockot@google.com
https://bugs.chromium.org/p/chromium/issues/detail?id=810905#c3

I think that this would be a great addition to the API for a couple of reasons. First, it would be consistent with it's current behavior ('status' is exposed as if it were a header). Second, for users, because I want to write an extension that helps QA people test server errors. Server errors are hard to trigger "for real" so it would be useful to simulate them. It's possible to simulate with a MITM proxy, but that's another piece of infrastructure to maintain. It would be TOTALLY RAD to allow extensions to modify the status line, in addition to all the other headers.

The only trade-off I can think of is that malicious extensions could make trouble. However, malicious extensions with 'blocking' permission can already cause incredible trouble, and this capability wouldn't be appreciably more than that.

P.S. This isn't really a defect on MacOS, but rather a feature request for the extension APIs. Please advise on how to file this feature request accurately, thanks.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36