Closed Bug 1736026 Opened 2 months ago Closed 2 months ago

Show HTTP status code in CORS messages logged to devtools console that can indirectly result from HTTP errors

Categories

(Core :: DOM: Networking, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
95 Branch
Tracking Status
firefox95 --- fixed

People

(Reporter: sideshowbarker, Assigned: sideshowbarker)

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

Problem

When a CORS request is sent to a server and the server responds with a 4xx or 5xx HTTP status code in the response, and the response doesn’t include the Access-Control-Allow-Origin header, the browser will always log a CORS error message to the devtools console — but may not (or even usually doesn’t) also log the HTTP status code to the console.

As a result, many (or most) developers who are in the process of trying to troubleshoot the server-side CORS config (on the server the request was sent to) only see the CORS error — but don’t see the 4xx or 5xx HTTP status code — and so then often (or usually) assume that there’s a mistake in their CORS config, when in fact the actual cause is that a 4xx or 5xx error occurred.

For some evidence and discussion of that problem, see the following:

The effect of that problem is that, every day, it causes hundreds if not thousands of developers to waste hours trying to troubleshoot and identify mistakes in their server CORS config — mistakes they never find, because in fact their existing CORS config is already working as expected and instead the real cause is some 400 or 500 or 502 or whatever.

The main reason those developers see CORS errors logged to the devtools console in those cases is that many (or most) runtimes/server systems by default do not add application-set response headers to 4xx and 5xx responses — including the Access-Control-Allow-Origin response header. (For example, Apache and nginx do not; in order to make them add the Access-Control-Allow-Origin response header to 4xx or 5xx errors, the always keyword needs to be added to the header-setting directive.)

Proposed solution

Make the HTTP status be included in all CORS messages that might get logged when a 4xx or 5xx error occurs. That means the following:

  • Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at %1$S. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

  • Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at foo. (Reason: CORS request did not succeed).

  • CORSPreflightDidNotSucceed2=Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at foo. (Reason: CORS preflight response did not succeed).

Internally, those are the messages with the property names CORSMissingAllowOrigin, CORSPreflightDidNotSucceed2, and CORSDidNotSucceed.

The proposal here is that in the case of, for example, a 500 error, those messages would instead be:

  • Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at %1$S. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 500

  • Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at foo. (Reason: CORS request did not succeed). Status code: 500

  • CORSPreflightDidNotSucceed2=Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at foo. (Reason: CORS preflight response did not succeed). Status code: 500

Assignee: nobody → mike
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c9da45719e55
Show HTTP status code in CORS messages r=necko-reviewers,emilio,valentin
Severity: -- → S3
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P3
Whiteboard: [necko-triaged]
Pushed by marcos@marcosc.com:
https://hg.mozilla.org/integration/autoland/rev/2b65a0fbcf8b
Show HTTP status code in CORS messages r=necko-reviewers,emilio,valentin
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch
You need to log in before you can comment on or make changes to this bug.