frigus02/RESTer

Clean request mode does not work in Chrome

frigus02 opened this issue · 3 comments

It looks like this issue has returned as of Chrome: Version 80.0.3987.132 (Official Build) (64-bit).
I've tried the "Clean Requests" and it continues to include the extra headers and does not overwrite Origin.

It looks like this issue is Unique to Chrome. I tested with the new msft edge and works just fine.

image

image

image

Originally posted by @walterstypula in #75 (comment)

I can mostly reproduce on Chrome Version 80.0.3987.132 (Official Build) (64-bit).

Clean Requests mode sends the following headers:

GET /echo HTTP/1.1
Host: 127.0.0.1:7373
Connection: keep-alive
Sec-Fetch-Site: none
Sec-Fetch-Mode: cors
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7

Browser Requests mode sends the following headers:

GET /echo HTTP/1.1
Host: 127.0.0.1:7373
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
Sec-Fetch-Dest: empty
Accept: */*
Sec-Fetch-Site: none
Sec-Fetch-Mode: cors
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7

The only headers stripped by the clean mode are "Accept" and "Sec-Fetch-Dest".

On Firefox 76.0a1 (2020-03-13) (64-bit) the clean mode still works as expected.

This seems to be related to recent changes in Chromes webRequest API: https://developer.chrome.com/extensions/webRequest#life_cycle_footnote

Starting from Chrome 79, request header modifications affect Cross-Origin Resource Sharing (CORS) checks. If modified headers for cross-origin requests do not meet the criteria, it will result in sending a CORS preflight to ask the server if such headers can be accepted. If you really need to modify headers in a way to violate the CORS protocol, you need to specify 'extraHeaders' in opt_extraInfoSpec. On the other hand, response header modifications do not work to deceive CORS checks. If you need to deceive the CORS protocol, you also need to specify 'extraHeaders' for the response modifications.

Starting from Chrome 79, the webRequest API does not intercept CORS preflight requests and responses by default. A CORS preflight for a request URL is visible to an extension if there is a listener with 'extraHeaders' specified in opt_extraInfoSpec for the request URL. onBeforeRequest can also take 'extraHeaders' from Chrome 79.

Starting from Chrome 79, the following request header is not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec:

  • Origin

Starting from Chrome 72, if you need to modify responses before Cross Origin Read Blocking (CORB) can block the response, you need to specify 'extraHeaders' in opt_extraInfpSpec.

Starting from Chrome 72, the following request headers are not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec:

  • Accept-Language
  • Accept-Encoding
  • Referer
  • Cookie

Starting from Chrome 72, the Set-Cookie response header is not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec.

I uploaded a new version for both Chrome and Firefox.

I have not uploaded a new version in a while and there are new privacy descriptions to fill out for the Chrome extension, which have to be reviewed. It might take several days for the new Chrome version to be available.