Re: [whatwg/fetch] Header to opt out of opaque redirect (#601)

Krinkle left a comment (whatwg/fetch#601)

@annevk From a web developer perspective, having used XHR for decades and having intimately worked on jQuery.ajax internals, and deployed APIs at scale that involve CORS, this is a distinction I've never come across until now.

I was sharing my expectation as a web dev, not as a reader of the spec. I understand (since last month) what the spec says about this.

To a first approximation, opaque responses on the web are analogous with cross-origin requests (i.e. lack of CORS is the only reason you'd not be able to read a response), and that "the thing" you do on a web server when you want to grant a client the permission to read a web response that it is isn't allowed to read otherwise, is to support CORS prelight negotiation and set Access-Control-Allow-Origin.

The spec today says the redirect restriction is separate and remains in effect regardless of this signal. I'm asking what the use case / web compat / security rationale is behind restricting read access to a response that has an explicit CORS allowance. I'm sure there's a good reason, and I don't think I'm going to convince you to change this. But.. I'd very much like to know what the reason is.

It seems like a clear and unambigious signal of intent. It could even work for same-origin requests by way of explicit `{mode: 'cors'}`. There is precedence with `<script crossorigin=anonymous>` which can already perform CORS requests to the same origin.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/601#issuecomment-2792596117
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/601/2792596117@github.com>