Fetch: content-length header is being added to the safe-list
Reported by
shac...@peer5.com,
May 9 2018
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36 Steps to reproduce the problem: 1. create a CORS fetch request to a url that has content-length in its response and doesn't add content-length to access-control-expose-headers 2. content-length should be accessible in the response's headers 3. What is the expected behavior? When doing a CORS fetch request if content-length exists in the http response it should be exposed on the response headers even if it's not added to the access-control-expose-headers. What went wrong? content-length is not exposed Did this work before? N/A Does this work in other browsers? N/A Chrome version: 66.0.3359.139 Channel: stable OS Version: OS X 10.12.6 Flash Version: see: https://github.com/whatwg/fetch/pull/626 https://github.com/w3c/web-platform-tests/pull/10930
,
May 9 2018
Trying again as monorail ate my tags
,
May 9 2018
,
May 9 2018
shachar@, during the repro, does the DevTools console have any messages like:
Blocked current origin from receiving cross-site document at
https://example.com/ with MIME type text/html.
?
I assume (based on mention of CORS) that the problematic response includes access-control-allow-origin response header? If it does, then I would expect CORB to allow the response (and so kCorsSafelistedHeaders in the Network Service [pointed out in #c1] shouldn't matter).
For now I assume that this bug is not related to CORB (*) in any way and instead is asking Chromium to add Content-Length to the list of headers in third_party/blink/renderer/platform/exported/web_cors.cc:
bool IsOnAccessControlResponseHeaderWhitelist(const WebString& name) {
DEFINE_THREAD_SAFE_STATIC_LOCAL(
WebHTTPHeaderSet, allowed_cross_origin_response_headers,
({
"cache-control", "content-language", "content-type", "expires",
"last-modified", "pragma",
}));
(*) CORB = Cross-Origin Read Blocking - see:
- https://github.com/whatwg/fetch/issues/681
- https://github.com/whatwg/fetch/pull/686
- https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md
,
May 9 2018
Let's wait until WPT changes propagate to Chromium.
,
May 10 2018
Issue 841307 has been merged into this issue.
,
May 10 2018
Tests arrives in https://chromium-review.googlesource.com/1052427.
,
May 10 2018
lukasza@, You're right this issue is about adding Content-Length to the list of safe listed headers in a CORS request - As the spec has changed
,
May 11 2018
The NextAction date has arrived: 2018-05-11
,
May 18 2018
,
May 18 2018
Ugh... quite a few legacy / non-WPT layout tests need to be updated...
,
Aug 14
Hey any update here? Edge fixed the issue - https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/17440391/ Webkit as well - https://bugs.webkit.org/show_bug.cgi?id=185473
,
Aug 14
mkwst@: I wonder if somebody more familiar with CORS tests could take this over. At any rate, since I am not actively working on this at the moment, let me change the status from Started to Available. PS. This is not really related to CORB (especially after r581035 landed).
,
Nov 30
cc-ing domfarolino@: Feel free to take this one. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by rsleevi@chromium.org
, May 9 2018