Should errors be considered same-origin or cross-origin?

[mfalken]

This came up in a Blink Intent to Ship.

HTML defines CORS-same-origin in a way that excludes 'error' responses. As a result, stylesheets that fail to load are considered cross-origin, so stylesheet.cssRules will throw a SecurityError.

Is this the recommended way specs interpret the Fetch response type 'error', and if so why?

I could imagine an alternative design we have 'error' and 'opaqueerror', where 'error' is network error from a same-origin URL and opaqueerror is a network error from a cross-origin URL. Was that type of design considered and rejected?

[annevk]

It's somewhat part of the way we "designed" errors that you cannot tell much about them. E.g., if the TLS handshake fails when establishing a second same-origin connection, is that a same-origin error?

I suspect that for new APIs we wouldn't use DOMException "SecurityError" though, we'd use TypeError or perhaps DOMException "NetworkError".

Hope that helps.

[mfalken]

Thanks. Following up on this, I changed Chrome to throw a SecurityError for a <link rel=stylesheet> that fails to load due to network error. There's a risk of breaking some sites that access cssRules expecting it to never throw. Indeed one Chrome test broke with this change because it was loading a file:// URL that didn't exist, and no one noticed until now. I'll see if reports come in. You can probably close this issue.

[annevk]

Thanks for the follow-up!