Cancelled XHR has no information
Reported by
michael....@gmail.com,
Dec 15 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 Steps to reproduce the problem: 1. Post a request from HTTPS 2. Respond to request with a 302 Redirect and a Location header of HTTP (Notice being redirected to an insecure url) 3. Chrome attempts to follow the redirect, realizes it's insecure, blocks the new request, and cancels the old. What is the expected behavior? When handling the readystatechange for the canceled request, XHR should have all of the response information, headers, status, url, etc. What went wrong? Instead, the XHR is an empty object with absolutely no information regarding the original request/response. This makes it impossible for a web developer to handle and react appropriately. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 55.0.2883.95 Channel: stable OS Version: OS X 10.11.6 Flash Version: Shockwave Flash 24.0 r0 The XHR in Firefox has all of the information. I've attached a screenshot of Chrome's and FF's responses.
,
Dec 16 2016
,
Dec 16 2016
,
Dec 16 2016
Redirect is handled in HTTP-redirect fetch (https://fetch.spec.whatwg.org/#http-redirect-fetch) which returns the result of main fetch (https://fetch.spec.whatwg.org/#concept-main-fetch). In the algorithm, it says " If should fetching request be blocked due to a bad port, should fetching request be blocked as mixed content, or should fetching request be blocked by Content Security Policy returns blocked, set response to a network error. [MIX] [CSP] " So I think the current behavior is spec-conformant. IIUC there is no reason to return a 302 response.
,
Dec 16 2016
You need to consider the security aspects of having the "network error" expose details about what failed, which is one good reason why it doesn't.
,
Jan 11 2017
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ajha@chromium.org
, Dec 16 2016