HTTP request header for prerender navigation fetch?

[noamr]

By enabling prerendering, we add more server load than what's needed to supply explicit user requests. This is especially true for address-bar-initiated prerendering, where the document can't opt out.

I believe it would be useful/important for monitoring and for other purposes that an HTTP header is sent with a prerendering navigation fetch to indicate that this is a prerendering request, and allow an early bail-out.

WDYT?

@jeremyroman @domenic @nyaxt

[nhiroki]

SGTM. The Speculation Rules Prefetch spec defines the Sec-Purpose: prefetch header for the purpose and also allows vendor-specific headers like Purpose: prefetch [spec].

5. Set a structured field value given (Sec-Purpose, purpose) in request’s header list.

Implementations might also send vendor-specific headers, like Chromium’s Purpose/prefetch, Mozilla’s X-moz/prefetch, and WebKit’s X-Purpose/preview, for compatibility with existing server software. Over time we hope implementers and server software authors will adopt a standard header.

The Prerender spec should have the similar text.

In the current implementation, Chromium sends the Purpose: prefetch [code].

[nyaxt]

+1. Should we align impl+spec so that Chromium should send Sec-Purpose: prefetch (for interop) + Purpose: prefetch (for legacy servers).

[noamr]

SGTM. The Speculation Rules Prefetch spec defines the Sec-Purpose: prefetch header for the purpose and also allows vendor-specific headers like Purpose: prefetch [spec].

5. Set a structured field value given (Sec-Purpose, purpose) in request’s header list.

Implementations might also send vendor-specific headers, like Chromium’s Purpose/prefetch, Mozilla’s X-moz/prefetch, and WebKit’s X-Purpose/preview, for compatibility with existing server software. Over time we hope implementers and server software authors will adopt a standard header.

The Prerender spec should have the similar text.

In the current implementation, Chromium sends the Purpose: prefetch [code].

Shouldn't it also send information about this being a prerender rather than a prefetch? Not sure where I stand on that but might be worth discussing.

[domenic]

@jeremyroman, are there any other steps from the prefetch spec that you think also apply to URL-bar-triggered prerendering?

Probably the storage partitioning/uncredentialed stuff will apply for page-triggered prerendering, but for URL-bar-triggered prerendering I'm not so sure.

Maybe setting the initiator??

[jeremyroman]

Yeah, I think for the cross-site case we're going to need to do the same thing as prefetch, plus equivalents for all the storage APIs etc. That's a rather large kettle of fish.

There's another issue that I haven't had the time to fully resolve about respecting prefetch-src, which is connected to initiator as specified today, I believe.

I do think we should send Sec-Purpose: prefetch (plus vendor-specific headers for compat if necessary). If we want to differentiate prerender requests (I'm not sure they need to be differentiated at request time, though), we can either add an additional element to the list (prefetch, prerender) or a parameter (prefetch; prerender) in a well-defined way. I'm not sure we should do that in advance of a known use case, though.

[noamr]

I do think we should send Sec-Purpose: prefetch (plus vendor-specific headers for compat if necessary). If we want to differentiate prerender requests (I'm not sure they need to be differentiated at request time, though), we can either add an additional element to the list (prefetch, prerender) or a parameter (prefetch; prerender) in a well-defined way. I'm not sure we should do that in advance of a known use case, though.

The use case I had in mind is to allow early opt-out from prerendering for origins who seek it.

[domenic]

OK, so I think we should ASAP spec Sec-Purpose: prefetch. It sounds like for UA-initiated prerendering the initiator won't matter much (since it's about CSP and there's no referring CSP that could be involved) so that's not urgent.

I think the spec here would be to basically monkey the navigate algorithm with a type parameter (maybe we could add a new navigationType, in addition to "form-submission" and "other"?), pass it in in https://wicg..io/nav-speculation/prerendering.html#start-user-agent-initiated-prerendering and https://wicg..io/nav-speculation/prerendering.html#create-a-prerendering-browsing-context , and then in process a navigate fetch (I think?) set the header appropriately.

[domenic]

Let's try to nail down the exact plan here.

• Spec Sec-Purpose: prefetch, for sure. We can do that now.
• Do we additionally spec that UA-specific headers are allowed? Probably, like Jeremy already did for prefetch. Although I personally wouldn't mind trying to get rid of that.
• Add a prerender indication to Sec-Purpose. I think our main choices are prefetch; prerender (i.e., prerendering is a "parameter" of the prefetching process) or prefetch, prerender (i.e., they are two separate-ish sibling purposes). I'm not sure which is better.

[jeremyroman]

re. UA-specific headers, at least for prefetch @KenjiBaheux was concerned that we'd lose existing server behavior that might already be sniffing for vendor values of Purpose, X-Moz, etc

[nyaxt]

The @domenic 's plan sounds good me.
I want to clarify what Chromium should implement now - should it strictly be only Sec-Purpose: prefetch or Sec-Purpose: prefetch in addition to Purpose: prefetch (which we send today)?

Re: list, I want to make it in a way that it allows fallback to prefetch when prerender is requested. There are two use-cases:

• Ideally the UA would like to prerender, but given the resource limitation, it cannot. It fallbacks to the prefetch.
• The UA prerendered the content, but now it needs to discard it (long time has passed without user navigating, etc.). We would like to still use the response to render the page.

[domenic]

I want to clarify what Chromium should implement now - should it strictly be only Sec-Purpose: prefetch or Sec-Purpose: prefetch in addition to Purpose: prefetch (which we send today)?

I am not sure. I think it would be good if we moved the world toward only standardized headers, so it would be nice to only use Sec-Purpose. However maybe it is important to not break existing sites that look for Purpose. It is hard to weigh these two in my mind.

I think probably the default path should be to send both, since that was what we previously agreed on and we don't really have any new information to make us change that decision.