Fetch API: When redirect mode is set to error, HTTPS => HTTP redirect must not invoke mixed-content checking
Reported by
ivoju...@gmail.com,
Feb 19 2017
|
|||||||||||
Issue description
Chrome Version : 58.0.3016.0 (Build oficial) canary (64 bits)
URLs (if applicable) : Any HTTPs origin
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Firefox: PASS (51.0.1 (32-bit), 53.0a2 (32-bit))
IE: N/A
What steps will reproduce the problem?
(1) Perform a HEAD request with 'error' redirect mode via the Fetch API to
an HTTPs location which redirects (301) to HTTP.
Sample code:
var targetUrl = 'https://www.animatedimages.org/data/media/209/animated-cat-image-0031.gif';
function checkResourceLocation(src) {
var request = new Request(src, {
method: 'HEAD',
mode: 'no-cors',
redirect: 'error'
});
return fetch(request).then(response => {
if (!response.ok) return Promise.reject(new Error(`Response status not OK.`));
});
}
checkResourceLocation(targetUrl).catch(err => {
console.log(err.message);
});
What is the expected result?
The fetch fails, and only the error message handling the promise rejection is written the console.
What happens instead?
The fetch fails, and multiple errors are written to the console at once.
E.g., when run in https://www.google.com.pe:
Mixed Content: The page at 'https://www.google.com.pe/' was loaded over HTTPS, but requested an insecure resource 'http://www.animatedimages.org/data/media/209/animated-cat-image-0031.gif'. This request has been blocked; the content must be served over HTTPS.
Fetch API cannot load https://www.animatedimages.org/data/media/209/animated-cat-image-0031.gif. Redirect failed.
Please provide any additional information below. Attach a screenshot if
possible.
- Making a GET request instead makes no difference in the result.
- Firefox works exactly as expected, and only warns when `mode` is set to 'cors' due to no Access-Control-Allow-Origin header.
,
Feb 21 2017
Able to reproduce the issue on Windows7, Mac 10.12.2 & Linux Ubuntu 14.04 using stable-56.0.2924.87, canary-58.0.3018.0 & reported version-58.0.3016.0 as per the below steps: 1. Launched chrome 2. Opened new Tab 3. press F12 to open dev tools 4. Navigate to Console 5. Copy & paste the above sample code & hit enter 6. Observed same error which is mentioned in the above attached screenshot same behaviour observed from M45-45.0.2454.101 to latest Canary & observed 'Uncaught exception error' for the earlier builds of M45.Since it is non regression issue marking this as 'Untriaged'. Please find the attached screencast for reference. Thank you!!
,
Feb 24 2017
Maybe this should be tagged Blink > Network > FetchAPI?
,
Apr 5 2017
,
Apr 5 2017
,
Apr 17 2017
Why do you want to get rid of the console messages? You would see it only when you attempt to perform mixed content loading which shouldn't bother you when writing real production apps.
,
Apr 17 2017
Ah, sorry. I understood. Given that the redirect options is error, it should reach the point where mixed content check happens.
,
Apr 17 2017
s/should/shouldn't/
,
Apr 17 2017
Indeed. I expect the warnings not to be emitted since I request an HTTPs resource and I disallow redirections. As for the use case, this is part of a client-side-only solution I came up with to prevent my app users from embedding mixed content that other users would be unable to see if using HTTPs.
,
Apr 17 2017
In the last sentence I meant: "if using HTTPs Everywhere". There is also the loss of the green lock for normal HTTPs users, which I want to prevent.
,
Apr 17 2017
This is because mixed-content checking is performed in ResourceLoader::WillFollowRedirect() before the ResourceLoader forwards the redirect to RawResource and then RawResourceClient which is DocumentThreadableLoader where Chrome stops loading when the redirect option is set to "error". This is not conformant to the Fetch Standard. When the redirect mode is set to "error", the fetch algorithm should return a network error right after the destination URL is extracted. Mixed-content check shouldn't happen.
,
Apr 17 2017
Thanks for providing the additional rationale.
,
Apr 17 2017
,
Nov 10 2017
,
Feb 18 2018
,
Apr 16 2018
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by ranjitkan@chromium.org
, Feb 20 2017