Cannot override request headers for redirect using continueInterceptedRequest |
|||||||
Issue descriptionChrome Version: 65.0.3325.146 OS: Linux (probably irrelevant) I'm trying to override request headers in Chromium headless, but overriding request headers for redirect using continueInterceptedRequest (https://chromedevtools.github.io/devtools-protocol/tot/Network#method-continueInterceptedRequest) does not work. For example, assume redirect4.pl redirects to echo-headers2.php?headers=HTTP_X_DEVTOOLS_TEST. I receive the follow three requestIntercepted events: 1) Network.requestIntercepted ID 2 GET redirect4.pl type: Script 2) Network.requestIntercepted ID 2 301 redirect redirect4.pl -> echo-headers2.php?headers=HTTP_X_DEVTOOLS_TEST 3) Network.requestIntercepted ID 2 GET echo-headers2.php?headers=HTTP_X_DEVTOOLS_TEST type: Script Note that the 3rd event is a HeadersReceived event, so at this point it's too late to override the request headers. It's possible to override the request headers for redirect4.pl in 1). However, setting the request headers in 2) does not change the headers sent to the server for echo-headers2.php. This is unexpected. What steps will reproduce the problem? (1) The attached patch adds a new LayoutTest that reproduces the issue. (2) Patch the file in your Chromium src directory. (3) $ python third_party/WebKit/Tools/Scripts/run-webkit-tests -t Release http/tests/inspector-protocol/network/redirect-interception-modified-headers.js (4) Notice how the diff has the expected 'X_DEVTOOLS_TEST: foo'. This means the header was correctly overridden for the echo-headers2.php request. (5) Comment the line iframe.src = '${testRunner.url('./resources/iframe.html')}'; and uncomment iframe.src = '${testRunner.url('./resources/redirect-iframe2.html')}'; (6) Rerun the test and now notice how X_DEVTOOLS_TEST is unset. This is unexpected. This happens because of the extra redirect.
,
Mar 26 2018
Bumping the priority since this will soon block some server-side work for Data Saver. We don't care about the particular milestone (we're using HEAD for this particular work). Let us know if you won't have time to get to this soon or if you have any pointers. We might consider sending a patch if no one can get to this soon (assuming the fix isn't too complex, given that we have no Chromium expertise ;) ).
,
Mar 26 2018
spelchat@, when redirect occurs the current implementation lets the net/ stack handle most of the redirect logic, and the interface (i.e. URLRequest::FollowRedirect()) does not expose an option to provide more headers. It's also a similar story with the new implementation which is based on the network service. However, it's pretty simple for us to cancel the request and start another in the new implementation, if the needs be. The question is, though, why you need this? Does the header you're adding depend on the current URL? Otherwise, specifying the additional header before the request is sent should work even in case of a redirect.
,
Mar 26 2018
> spelchat@, when redirect occurs the current implementation lets the net/ stack handle most of the redirect logic, and the interface (i.e. URLRequest::FollowRedirect()) does not expose an option to provide more headers. I see. Thanks for the explanation! > why you need this? We need to annotate each request with a header specifying the resource type (e.g. Document, Script, etc.). Each request is handled by a proxy, which needs to process the request differently depending on the resource type. We cannot rely on Content-Type of the response since it may be wrong. > Does the header you're adding depend on the current URL? Not the URL specifically, but it depends on how the resource will be used. If you mean "does the header change depending on the particular request?", then the answer is yes. If you mean "do you care about the URL the request is redirected to?", the answer is no. Thanks!
,
Mar 26 2018
Ok, so it sound that you don't really need to supply headers during the redirect, the resource request is known before we send the request, so setting the headers before the request should have effect both on what we send with the original request and what is sent with requests happening because of the redirect. Are you saying it doesn't?
,
Mar 26 2018
> setting the headers before the request should have effect both on what we send with the original request and what is sent with requests happening because of the redirect. Are you saying it doesn't? That's correct. Adding a request header in continueInterceptedRequest for all intercepted requests never modifies headers for redirect requests.
,
Mar 29 2018
Thanks and sorry for initial misunderstanding -- I could reproduce this now. The fix is coming: https://chromium-review.googlesource.com/c/chromium/src/+/985554 BTW, this already works as expected with the new interception implementation (i.e. with --enable-features=NetworkService).
,
Mar 29 2018
Great! Thanks for the quick work!
,
Jan 10
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by eostroukhov@chromium.org
, Mar 19 2018Status: Assigned (was: Untriaged)