Allow developer to view response blocked by No 'Access-Control-Allow-Origin' header
Reported by
ocie.mit...@gmail.com,
Nov 14 2016
|
||||||
Issue description
Chrome Version : 54.0.2840.71
OS Version: OS X 10.11.6
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
Firefox 4.x:
IE 7/8/9:
What steps will reproduce the problem?
1. open devtools network tab
2. try to retrieve CORS content that has no 'Access-Control-Allow-Origin' header. eg. $.ajax('http://google.com')
3.
What is the expected result?
The app developer is able to use the network tab to view the response, even though the initiating script sees this request fail.
What happens instead of that?
The network tab does not show the response. The app developer has to use external tools such as postman, curl, etc. to view the response. Often times, recreating the proper environment (copying access tokens, URL parameters, headers) is a tedious and error-prone task.
Please provide any additional information below. Attach a screenshot if
possible.
Even though the script should not be able to view the response, it can be helpful to allow the developer to see that response. The contents of the response can indicate the reason for the failure or give clues as to why the proper 'Access-Controll-Allow-Origin' header was not supplied in the response.
UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36
,
Nov 16 2016
Unable to reproduce the issue on Windows 7,Mac 10.11.6 and Linux Ubuntu 14.04 using chrome stable version-54.0.2840.99 & latest canary version-56.0.2920.0 as per the steps mentioned in Comment#0. Please provide us the sample html file and screen cast to reproduce the issue further. Please find the attached screen cast for reference. Thank you.
,
Nov 20 2016
Attaching sample html. Running this in the browser will give the following error in the console: XMLHttpRequest cannot load http://www.rupert.id.au/resources/4000-most-common-english-words-csv.csv. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost' is therefore not allowed access. Note, that is expected behavior because the Access-Control-Allow-Origin header is not present in the response. However, in a development scenario, a common development troubleshooting step is to copy the URL and use curl, wget, or some other tool to retrieve the resource to see if the response provides any insight as to why the original request failed. The URL is provided in the error, so the developer can click on it to see what the response is. This doesn't provide a way to view the response headers and doesn't include the request headers (like x-header1 in the example). Often the API response includes headers that can be used to diagnose the issue on the API server. To troubleshoot this API issue, the developer is forced to leave the Devtools and copy several request parameters to another tool to troubleshoot the problem, which is time consuming and error-prone.
,
Nov 21 2016
I am not asking for the results to be passed back to the requesting script, just to have a way to view the request in the network analysis pane as if the request had gone through correctly.
,
Nov 29 2016
Thank you for providing more feedback. Adding requester "jmukthavaram@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 27 2016
,
Feb 14 2017
Assigning to pfeldman@ for devtools triage.
,
Feb 14 2017
Hey Blaise, is there a way to report this request with a dummy response upon cors failure?
,
Jul 20 2017
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by tapted@chromium.org
, Nov 16 2016Labels: OS-All