Sending a `Purpose: prefetch` header for prefetched resources

[yoavweiss]

Chrome seems to be setting a Purpose: prefetch header for prefetched resources. I'm not sure what other implementations are doing.

This is not documented in the spec, but seems to be something developers are interested in. (presumably in order to tell apart in their server-side analytics which resources were prefetched vs. which ones were explicitly needed by the browser)

We should probably add it to the spec (or decide that it's an awful, awful idea and file bugs against implementations that do that).

[igrigorik]

Sounds like a good plan 👍

[jyasskin]

To what extent does this header interact with Sec-Metadata and friends?

@mikewest

[jyasskin]

Anne suggests we specify this header in Fetch, by keying off the initiator. He points out that we need to also decide which of the lists starting at https://fetch.spec.whatwg.org/#cors-safelisted-request-header it should appear in. We can imitate whatwg/fetch#751 to actually add the header.

[annevk]

FWIW, I suspect we probably don't want to add it to any list.

[kinu]

While discussing how cross-origin prefetch could be processed we came across this one; if we want to make all cross-origin prefetches non no-cors (and it feels we should) we probably should 1) document this header in the spec, and 2) add it to the reasonable cors safelist or consider renaming the header name to something like 'Sec-'.

[toyoshim]

@annevk do you have any specific reason why we don't want to?

I'm working on re-designing of Chrome CORS implementation so that we can do the most things outside the renderer processes safely, and notice that this Purpose header triggers CORS preflight in the new implementation.

If we allows JavaScript to specify this, we want to add it to the CORS-safelisted request-header (https://fetch.spec.whatwg.org/#cors-safelisted-request-header). Otherwise, adding to the forbidden header name (https://fetch.spec.whatwg.org/#forbidden-header-name), or using 'Sec-' prefixed header name sounds preferable answer for this. IMO, the purpose header should be fully controlled by user-agents. So, forbidden is the right list.

[annevk]

In that case adding the Sec- prefix would be best as otherwise legacy user agents can be used to confuse the server.

Ideally these lists are largely treated as immutable as otherwise clients and servers have moving targets for maintaining SOP protections.

[yoavweiss]

@annevk thoughts on wholesale safelisting anything with a Sec- prefix? Presumably servers should not be vulnerable to those, and they cannot be added by (potentially malicious) developers.

[annevk]

@yoavweiss I think that's the rough consensus. That browsers are allowed to emit new Sec--prefixed headers across origin boundaries and that servers should not be surprised by them. The values of those headers should still largely be outside the control of attackers though. At some point we should document that.

[yoavweiss]

@annevk That's great. I currently have that logic as part of the Client Hints PR, but happy to spin it off to a separate PR, if you think it's something we can land sooner.

[annevk]

@yoavweiss interesting, that definitely seems like something that's worth splitting out and tackling separately.

[yoavweiss]

@annevk - will do!

[toyoshim]

As I also commented at #880, Sec- prefix is already in the Fetch spec.
https://fetch.spec.whatwg.org/#forbidden-header-name

We should not move it from the forbidden list to the safelist. It causes a security risk. Since Sec- headers are ensured that they are not set by JavaScript but by user-agents, servers can accept them safely. Otherwise, we should make a CORS preflight request.