Ability to detect CORS failures vs connection failures

[jakearchibald]

And potentially other kinds of failures too.

In background fetch we might consider retrying a GET request in event of a connection failure. However, if the request failed a CORS check, there's little point in retrying.

I'm happy for this to live in spec-land. Later, we could consider exposing it via an error type, or the fetch oberver.

I guess response could have an failure reason. A value of "aborted" would probably replace the aborted flag from https://github.com/whatwg/fetch/pull/523/files.

[annevk]

This seems very similar to #526. The main problem is that we don't want to expose that granularity to content necessarily. We don't want you to be able to know whether a given server exists, but it was just the same-origin policy that prevented you from knowing that.

[jakearchibald]

Isn't this already exposed by the various no-cors APIs?

Anyway, I'm mostly interested in exposing this at a spec level, so I guess this is a dupe of #352.

[annevk]

I guess it is somewhat, indeed. Though no-cors reveals response vs error, but does not reveal CORS error. And a response to a CORS request to the same URL could be different from no-cors due to the additional request header. So you'd still have additional leakage.

And if you're planning on using the new hooks we'd have to evaluate if that usage doesn't reveal anything new either.