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

Krinkle left a comment (whatwg/fetch#601)

**Use case**: Wikipedia has a redirect service at https://w.wiki ([UrlShortener](https://www.mediawiki.org/wiki/Extension:UrlShortener) MediaWiki extension). Some clients would like to resolve and expand these programmatically ([T358049](https://phabricator.wikimedia.org/T358049)).

**Workaround**: It would seem that we need to build and provide a separate API endpoint for this, instead of being able to let HTTP standards and the web platform speak for themselves. In particular, this needlessly adds bariers to discovery (Does it have an API? Where is it?), engineering effort due to lack of interoperability (What params does it take? What format does its response use?), and for our infastructure: increases load and decreases caching potential as we can't have our Varnish-based CDN re-use cached responses from the redirect service, as these would be distinct endpoints.

**Expectation**: I am not surprised by the default `opaqueredirect`, given the conservative exposure of headers and desire not to increase attack surface beyond XSS (per <https://fetch.spec.whatwg.org/#atomic-http-redirect-handling>).

However, I was expecting that adding `Access-Control-Allow-Origin: *` would allow clients to read the response like so:

```js
var resp = await fetch('https://w.wiki/DeCk', { method: 'HEAD', mode: 'cors', redirect: 'manual' });
resp.headers
```

Failing that, I realized [CORS-safelisted response-header name](https://fetch.spec.whatwg.org/#cors-safelisted-response-header-name) is a thing and added `Access-Control-Expose-Header: Location` or `Access-Control-Expose-Headers: *`. I was expecting this to either result in a non-empty Header on the `opaqueredirect` response and/or swap it for a `basic` response.

This expectation is met, when the reponse is anything but a redirect (i.e. 200 OK, or 404 Not Found), but when the response is HTTP 301, the data disappears, which is surprising.

**Question**: It is not obvious in what scenario this would provide security benefits, i.e. when would it be surprising to _not_ expose headers, given that the safelist of header is not specific to redirects, either. Is there a web compat angle here?  Or, perhaps this sample case could be addressed this way, but maybe there are other redirect-related use cases that we want to address at the same time and perhaps this approach could not work for some of those? I'd love to know.

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

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