New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 661782 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Leaves the project on 2018/03/02
Closed: Dec 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Preserve custom headers when following cross-origin redirects

Reported by j...@nottheoilrig.com, Nov 2 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.113 Safari/537.36

Example URL:
http://w3c-test.org/fetch/api/cors/cors-redirect-preflight.html

Steps to reproduce the problem:
1. Make a same-origin request with custom headers: fetch('http://SAME.example', { headers: { 'X-ServiceWorker-Test': 'test' } })
2. Receive and follow a cross-origin redirect: to http://OTHER.example

What is the expected behavior?
The custom header is present in both the initial request to http://SAME.example and the subsequent request to http://OTHER.example

What went wrong?
The custom header is present in only the initial request to http://SAME.example

Did this work before? N/A 

Chrome version: 53.0.2785.113  Channel: n/a
OS Version: 
Flash Version:
 
I'm interested in working on this issue. I cooked up a CL to address it [1].
Chromium already preserves CORS-safelisted headers, so in general, the approach I have in mind is to extend this code to cover custom headers as well [2].
 Issue 162183  introduced the code that preserves CORS-safelisted headers.

[1] https://codereview.chromium.org/2471533005
[2] https://chromium.googlesource.com/chromium/src.git/+/master/third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp#202
I'm interested in working on this issue. I cooked up a CL to address it [1].
Chromium already preserves CORS-safelisted headers, so in general, the approach I have in mind is to extend this code to cover custom headers as well [2].
 Issue 162183  introduced the code that preserves CORS-safelisted headers.

[1] https://codereview.chromium.org/2471533005
[2] https://chromium.googlesource.com/chromium/src.git/+/master/third_party/WebKit/Source/core/loader/DocumentThreadableLoader.cpp#202
Labels: TE-NeedsTriageHelp
Cc: mkwst@chromium.org mmenke@chromium.org
Components: -Internals>Network Blink>SecurityFeature
I assume this behavior is deliberate, and respects the fetch spec.

Comment 5 by mkwst@chromium.org, Nov 3 2016

Cc: annevank...@gmail.com
Owner: tyoshino@chromium.org
Status: Assigned (was: Unconfirmed)
I think the correct behavior would be to preserve the headers, but preflight on the redirect. We also need to ensure that we're doing the rest of the checks in https://fetch.spec.whatwg.org/#concept-http-redirect-fetch correctly.

tyoshino@: Would you mind taking a look at the uploaded patch, and the related test results? We're failing 20/30, Firefox is only failing 10. :)
Can this issue be marked fixed now?
Components: Blink>Network>XHR Blink>Network>FetchAPI
Labels: Hotlist-Interop
Status: Fixed (was: Assigned)
Yes. Thanks jack for fixing this.
Thank you for helping me with it!
Cc: tyoshino@chromium.org
 Issue 689575  has been merged into this issue.

Sign in to add a comment