Issue said that Mike would be take a look, so assigned to him.

tyoshino@: Can you triage this?

CORS check can success even when the received response's HTTP status is 4XX or 5XX. The CORS protocol is independent from the rest of the contents of a response.

https://fetch.spec.whatwg.org/#cors-check

Doesn't the console error message you get include something like the following in addition to "No 'Access-Control-Allow-Origin' header is present ..."?

"The response had HTTP status code 400."

This is shown when the status code is equal or greater than 400.

hey! So I don't have time right away to repro locally but here's an example thread https://github.com/github/fetch/issues/301

See the screenshot of the console.

The first line is the HTTP error (the red GET). But the second line has a bunch of goop about CORS. This makes it confusing to developers because the second line has a lot more text and seems like the more important error. I feel like if the load error'ed out as a 400; there is no point in even showing the CORS errors.

Do you agree that this could be confusing to someone who doesn't understand CORS?


I agree with you that CORS is a separate spec but most developers don't care and the current behavior is confusing. This is purely a usability improvement. 

+toyoshim@

OK. Fair enough. This message could be improved to give the most useful advice to developers. Maybe change of phrase ordering, removal of phrases or change of conditions.

Sounds like a matter of taste?
A server may intentionally returns 400 always just to reject CORS requests, but another may fail to provide an expected A-C-A-O due to server troubles, resulting in 4xx/5xx. So both information will be informative for users, but it depends?

yes. This is totally a matter of taste and I think even cleaning up the CORS errors to say "The server returned a 4xx. The 4xx response also failed the CORS check." which on clicking gives full details of the CORS error will be enough to clarify to developers. Right now, in my experience, most developers get confused.

My team doesn't have time to work on this. Sending to DevTools for retriage in case they have some time to work on it.

I have a plan to plumb the http status to the DevTool console messages in most cases. I was actually shown in some cases, but temporarily disabled to have consistent behavior between the legacy CORS impl and my new out-of-renderer CORS.

Since I'm taking a leave now, it does not happen soon. If anyone is interested in this, please feel free to take it. But for now, I'd assign myself.

What is the status of this issue?

OOR-CORS is now under Canary/Dev field study, and will go to Beta.
But at this moment, we haven't made any change for this.

If someone is interested in this, please take the owner.

Probably, we can log the status code as a part of network log in the DevTool, rather than embedding it into the CORS console error message at blink::cors::GetErrorMessage.

In the network log, today, we just say

> GET <url> net::ERR_FAILED

but this could have the status code additionally. The status code is usually stripped in such error case, and needs to be plumbed.