XHR with cross-origin redirect scrubs bad content-types instead of redirecting
Reported by
manishsm...@gmail.com,
Jun 7 2016
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0 Example URL: Steps to reproduce the problem: - Run `nc -l 9001` locally to capture the redirect - Open http://manishearth.anapnea.net/tmp/test-redirect.html - Note that a preflight doesn't happen, but the nonstandard x-pony content-type is scrubbed What is the expected behavior? A preflight fetch should occur on localhost:9001, to check if the content-type header is an allowed one See https://fetch.spec.whatwg.org/#cors-safelisted-request-header and https://fetch.spec.whatwg.org/#concept-http-fetch step 4 What went wrong? Instead of a preflight fetch, it did a direct GET request with the content-type header scrubbed. Did this work before? N/A Chrome version: Channel: n/a OS Version: Flash Version: Shockwave Flash 11.2 r202 Firefox does this wrong too (differently), corresponding bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1278493
,
Feb 14 2017
It does look like we should be setting the content type and triggering a preflight. WDYT, tyoshino@? I know you've done work here in the last ~year (sorry for the delay!). Is this already fixed?
,
Nov 10 2017
,
Feb 18 2018
,
May 7 2018
tyoshino is gone and so is the original repro. Does anyone want to pick this up?
,
May 8 2018
I will fix this in following up works of OOR-CORS. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by rsleevi@chromium.org
, Jun 7 2016Components: -Internals>Network Blink>SecurityFeature