spec should be clearer about what CORS-same-origin means

[dbaron]

The HTML spec defines the term CORS-same-origin which in turn references the concept of response type defined in fetch. The fetch spec doesn't actually contain any description of how the response "type" is set (at least based on the internal spec links for the term), so it's very hard to tell what this means.

While investigating Issue 1477672: Stylesheet loading quirk incorrectly allows loading data: with non-CSS MIME type which can hang Chromium I reached this definition from 4.6.7.21 Link type "stylesheet".

Based on the spec I couldn't even tell whether CORS-same-origin is the result of a same-origin check or the input to a same-origin check, never mind any details about what it means. It would be helpful if HTML (in the definition of CORS-same-origin) or fetch (in the definition of response type) gave some hint as to what this meant (and how it's intended to be used by other specs) so that readers of specs wouldn't need to search other specs for the algorithms that set this state.

[annevk]

It's the result. It essentially indicates it's safe to do whatever with a response that is CORS-same-origin. (It also implies that redirects leading up to this response were also CORS-same-origin.)

[zetafunction]

So "CORS-same-origin" means one of the following is true for the response (and any intermediate redirects):

• same-origin
• or allowed by CORS (i.e. Access-Control-Allow-Origin)?

[dbaron]

In the case I was interested in, "same-origin with what?" is an interesting question, because it was about stylesheet loads, which could potentially be same-origin with the sheet that caused the load via an @import but still cross-origin with the document.

[zetafunction]

I /think/ that should be same-origin WRT to the request's client [1]. But you're right that it doesn't seem to be clearly documented.

[1] https://fetch.spec.whatwg.org/#:~:text=Set%20your%20request%E2%80%99s%20client%20to%20the%20environment%20settings%20object%20you%E2%80%99re%20operating%20in.

[zetafunction]

Of course, as soon as I posted that, I realize requests have an origin which is set during fetching: https://fetch.spec.whatwg.org/#concept-request-origin

[zetafunction]

And it's set here: https://fetch.spec.whatwg.org/#:~:text=If%20request%E2%80%99s%20origin%20is%20%22client%22%2C%20then%20set%20request%E2%80%99s%20origin%20to%20request%E2%80%99s%20client%E2%80%99s%20origin.

And the request's origin is used in a number of checks, and presumably for purposes of determining CORS same-origin as well.

[annevk]

It's a good question what should happen for stylesheet loads. That question also applies to module scripts. I'm guessing in both cases the authority we have chosen is the document, but whether that is the ideal solution I'm not sure. (It makes it harder to reuse the script or stylesheet across origins.)

cc @noamr

[noamr]

It's a good question what should happen for stylesheet loads. That question also applies to module scripts. I'm guessing in both cases the authority we have chosen is the document, but whether that is the ideal solution I'm not sure. (It makes it harder to reuse the script or stylesheet across origins.)

cc @noamr

This is actually well defined IMO. The context is always the document and not the importing stylesheet. See for example origin-clean. When we fetch a style resource, which includes @import statements, the client is the relevant settings object which is the document. The referrer, in cases like fonts, can be overridden to be the referring stylesheet URL rather than the document

Having said that, of course we can improve the informative notes about this.

[dbaron]

For what it's worth, I realized that one of the thing that was confusing me was that when I searched through the fetch spec, the definitions of "basic filtered response", "CORS filtered response", etc., at https://fetch.spec.whatwg.org/#concept-filtered-response-basic are actually definitions that are writing the response type, whereas reading the definitions I read the definitions as reading the response type. I wonder if the terms should actually be algorithms like "create a basic filtered response" etc.

[annevk]

I'd be open to some kind of refactoring to make that clearer.