Issue metadata
Sign in to add a comment
|
Network.requestIntercepted event fires but doesn't apply header modifications when following a redirect (301/302)
Reported by
gl...@otainsight.com,
Dec 27 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/604.3.5 (KHTML, like Gecko) Version/11.0.1 Safari/604.3.5 Steps to reproduce the problem: 1. Attach to the chrome remote interface 2. Enable Network.setRequestInterception() 3. Modify/add a header in the Network.continueInterceptedRequest() 4. Browse to any page that returns a HTTP 301/302 What is the expected behavior? Browser intercepts the request to the 301 url, adds the custom header Browser intercepts the request to the redirect destination, adds the custom header What went wrong? Browser intercepts the request to the 301 url, adds the custom header Browser intercepts the request to the redirect destination, but doesn't add the custom header anymore Did this work before? No Chrome version: 63.0.3239.84 Channel: stable OS Version: OS X 10.13.1 Flash Version: I originally raised this issue in the puppeteer github repository https://github.com/GoogleChrome/puppeteer/issues/1664. There we found out the bug isn't puppeteer specific but is also occurs when connecting to the chrome remote interface directly. Code samples to reproduce the problem both with puppeteer and with chrome-remote-interface directly can be found on the github issue.
,
Dec 28 2017
,
Jan 9 2018
Bug is not OS specific
,
Jan 16 2018
Another related issue, request method is incorrect after redirecting with Network.setRequestInterception() https://github.com/GoogleChrome/puppeteer/issues/1776
,
Mar 16 2018
FYI, i just tested this bug again on the latest build from master, which includes the new URLLoader based interception proxy (https://chromium-review.googlesource.com/c/chromium/src/+/956685) but the bug is still present.
,
Mar 16 2018
glenn@, the new URLLoader-based interception proxy is currently only used when network service is enabled, did you try with --enable-features=NetworkService? (caution: both support for the network service and new interception implementation are work in progress, a lot of other stuff may break).
,
Mar 16 2018
caseq@, that was indeed a piece of the puzzle I was missing. With the --enable-features=NetworkService flag this bug is indeed resolved, great! Is there a timeline for this to be considered stable (days, weeks, months?)? In the meantime I'll check if running this build with the flag raises any other issues for our specific use cases.
,
Jan 10
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by krajshree@chromium.org
, Dec 27 2017