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.

[toyoshim]

Anyway, it looks we agreed that renaming the Purpose header to Sec-Purpose is preferable.
So, I will make this change in Chrome 75.

This header haven't spec-ed until today, but it will be a breaking change for users who already relies on that. @yoavweiss , do you know how widely is this header already known and used? Or any concern if I make this change in the 75?

[yoavweiss]

any concern if I make this change in the 75?

No particular concerns, but it seems like something that would benefit from an Intent.

[akhiljay]

Hi @yoavweiss , just checking in here. Our team at Amazon is looking to leverage the "purpose: Prefetch" request header. Is it advisable to still use the same header or has the working group formalized a header format for prefetch requests?

[yoavweiss]

No progress to report on just yet. Sorry. I'm hoping progress would be made here soon...

[mfalken]

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

@mikewest

@mikewest at https://bugs.chromium.org/p/chromium/issues/detail?id=942976#c14 expressed not wanting both Sec-Purpose and Sec-Fetch-Dest.

Could it make sense to add prefetch to https://fetch.spec.whatwg.org/#requestdestination? I'm not sure: we lose the info about what the type of resource the prefetch is for.

Perhaps it is just an issue with naming, and this could be a header like Sec-Prefetch: true instead of Sec-Purpose?

[mikewest]

I might have misunderstood how prefetch integrates into Fetch. My understanding (based on the table just below https://fetch.spec.whatwg.org/#request-destination-script-like), is that prefetch and prerender are enum values of a request's "initiator", and that the corresponding destination is the empty string. In that case, it would make sense to me to define a destination of prefetch, and send it via Sec-Fetch-Dest.

If things work differently, such that prefetched resources have a defined destination, then I agree that it would make sense to define some other mechanism of representing it. Would exposing the initiator directly be reasonable? That would have the advantage of exposing a "download" intent as well, which could be helpful when servers are making decisions.

If not, then a Sec-Fetch-Preload: ?1 header, similar to the Sec-Fetch-User header, seems like the simplest way of aligning this information with the rest of fetch metadata.

[mfalken]

Good point, this was actually a similar discussion we were also having, and I filed a new bug at whatwg/fetch#1252 about whether destination should be the empty string for these.

I don't see an issue with exposing the initiator but am not well-versed in the implications of doing so. Assuming it is acceptable, would it be exposed as something like Sec-Fetch-Initiator in that case?

[mikewest]

I think my only concern with Sec-Fetch-Initiator is that I'm not sure it's useful enough to justify being sent on every outgoing request. download and prefetch/prerender seem like the only interesting values that aren't replicated as destinations; if those are the only things we care about, then mirroring the values in the destination seems like a simpler way of doing things that doesn't add any header overhead.

If there's good reason not to mirror the value, then I think it'd be worth looking into Sec-Fetch-Pre{fetch,load,render}: ?1 instead, as we could leave that off the vast majority of outgoing requests (similar to Sec-Fetch-User).

[mikewest]

/cc @arturjanc and @lweichselbaum, who might have thoughts about initiator values in request headers.

[arturjanc]

I fully agree with the approach described in #74 (comment) and don't have much to add. Specifically, Sec-Fetch-Dest: prefetch seems like a natural option to me, but if that doesn't work Sec-Fetch-Pre{fetch,load,render}: ?1 looks reasonable as well.

[yoavweiss]

Chromium is using <link rel=prefetch>'s as attribute value to determine if it's destined for top-level navigations or not (in unspecified ways :/).

If we want to properly specify that behavior, it makes sense to keep prefetches' destinations intact. If that's the case, Sec-Fetch-Pre* would be a better option.

[mikewest]

If Chromium is doing a thing, properly specifying the thing (or changing the thing so that it matches the existing spec) sounds like a good idea. :)

I don't have strong feeling about the direction y'all choose here. I think either option we're discussing is defensible. Which would y'all prefer?

[kinu]

Chromium's behavior has been trying to formulate things on top of the existing spec'ed concepts (i.e. initiator and destinations are orthogonal and prefetch also has as= attribute), we can remove the behavior with as= attribute if we want to reconsider the part, but we'll want to keep having some indication (at fetch layer) for 'prefetching resources for next navigation' cases anyways. The WIP spec text for the document-level prefetch (or prerender) is being developed/discussed here (in my understanding): https://github.com/jeremyroman/alternate-loading-modes/blob/main/fetch.md

For prerendering if we mirror 'prerender' to the destination it feels it's a bit unclear what Sec-Fetch-Dest headers subresource fetch requests for prerender should use. If we just use 'prerender' it'll lose the real final destination context, but if we just use the final destination it'll lose the context that it's for prerendering.

With these contexts I'd vote for Sec-Fetch-Pre{fetch,load,render}: ?1 (but can be convinced if others have reasons not to prefer this one / other better alternatives for above cases)

[yoavweiss]

Should be defined as part of #86

/cc @noamr

[tigt]

It looks like Firefox sets an x-moz: prefetch header for this, so hopefully they’d have no problem switching to a standardized header instead.

[noamr]

whatwg/html#8111 now specifies Sec-Purpose: Prefetch as the header.
I feel like we should really settle on something here. Currently firefox sends x-moz, Chromium sends purpose, and Safari doesn't support prefetch yet. Can we agree on Sec-Purpose: Prefetch? Something else?