Extensions are no longer able to add response headers to navigationPreload requests |
|||
Issue descriptionChrome Version: 71.0.3578.80 OS: MacOS 10.13.6 What steps will reproduce the problem? (1) install an extension that can add response headers (i use requestly - https://chrome.google.com/webstore/detail/requestly-redirect-url-mo/mdnleldcmiljblolnjhpnblkcekpdkpa?hl=en) (2) add a response header "foo" (3) navigate to https://cvazac.netlify.com/sw-nav-preload/index.html?preload=true (which installs service worker) (4) reload the page (so that service worker can execute a navigation preload) and open the console What is the expected result? You should see the following in the console: nav preload foo What happens instead? We don't see a message for header "foo". I've bisected to this commit: https://chromium.googlesource.com/chromium/src/+/c66f36032447e28a08591874395ca8fbeb47ba19 This works in < 71. Presuming this is not by design, I believe we need navigation preloads to flip the `is_browser_side_navigation` flag to true so that `HideRequest()` return false instead of true here: https://cs.chromium.org/chromium/src/extensions/browser/api/web_request/web_request_permissions.cc?type=cs&q=is_browser_side_navigation&sq=package:chromium&g=0&l=267. I would be happy to put together a CL, but don't want to go through the effort if this change was by design.
,
Dec 11
Thanks for the bisect. The CL changed browser initiated requests (except navigations) to be hidden from extensions. I am not that familiar with navigation preloads. Will look more into it. Can you elaborate on your use case? Adding other folks who might have an opinion on whether navigation preload requests should be visible to extensions.
,
Dec 11
Enabling navigationPreload is done so as to not block the navigation GET on service worker boot-up. IMO navigation preloads should be treated as normal navigations in this case. They are user initiated and their responses get rendered in the browser.
,
Dec 12
Yes, I may lack necessary context, but I would expect navigation preload requests to be treated like navigation requests in this case.
,
Dec 21
Setting requests headers via extensions are also affected by this change. For example, if you set a request header via any of the popular header extensions, the header will be sent on the user initiated request (first) but will not survive subsequent requests. For instance, say a 301 redirect occurs, the header will not be passed to the subsequent page. This worked in v70. Any chance the priority can be bumped up higher? This change has broken testing and validation processes.
,
Dec 21
Can you give a reproducible example michael.arlt.mail@?
,
Dec 21
To reproduce: 1 - install your favorite extension for modifying headers. For example: modheader, modify header, requestly, etc 2 - Use the extension to set a request header. Say "foo=1" 3 - visit a page that renders a 301 redirect. (For example, say you have a website that has deprecated /foo/1 in favor of /bar/2, but you want test sending a special header to /bar/2 via /foo/1) 4 - Note that the request header "foo=1" is passed on the client initiated page 5 - Note that the request header "foo=1" is not passed the redirected page (browser initiated) Prior to v71 the request header "foo=1" is passed to the redirected page. Additionally, the header was being passed to all other javascript initiated client calls made by the browser.
,
Jan 9
Issue 850865 has been merged into this issue.
,
Jan 9
|
|||
►
Sign in to add a comment |
|||
Comment 1 by dtapu...@chromium.org
, Dec 11