same-origin/cors requests and opaqueredirect

[wanderview]

I'm sorry if we've discussed this before, but what is the motivation for hiding manual redirect responses for same-origin/cors requests behind an opaqueredirect filtered response? It seems for same-origin and cors it should be ok to know the status and location header.

For additional context, hiding the data in an opaque-style response has additional costs when stored in the cache API. To avoid leaking information through the storage.estimate() API generally these responses have to be padded out with a large amount of quota space. This seems very punitive for same-origin and cors responses.

[wanderview]

I guess navigate requests are where manual redirect mode is normally used. Those are essentially "same-origin", but since they are a navigation don't have any primary context to be cross-origin from.

In that case, though, the service worker is by definition same origin to the opaqueredirect URL. I still don't understand why we have to hide the location header from the same origin that produced the location header.

[annevk]

https://fetch.spec.whatwg.org/#atomic-http-redirect-handling

[wanderview]

Hmm, ok. Thanks.

[annevk]

See #601 for an opt-in approach to exposing them anyway, but I suspect that was not your motivation for filing this.