103 Early Hints response processing during navigation

[bashi]

A 103 Early Hints response is an informational response a server can send before the final response to give a client some hints to optimize rendering pages (e.g. preloading critical subresources such as JS and CSS). For details about the motivation and use cases, please refer to the explainer. TAG review was completed.

103 are typically useful for navigation. We would like to specify 103 processing in the process a navigate fetch algorithm.

We’d propose the following changes in the Fetch standard and the HTML standard:

• [Fetch] Add a new optional argument processEarlyHintsResponse to the fetch operation. It takes an algorithm that will be passed a header list coming from a 103 response. Indicates a 103 response has been received. The value is plumbed via fetch params.
• [Fetch] Update the HTTP-network fetch algorithm. Stop ignoring 103 if processEarlyHintsResponse is given. Instead, retrieve a header list from a 103 response and queue a fetch task given fetchParam's processEarlyHintsResponse and the header list.
• [HTML] Pass processEarlyHintsResponse in the process a navigate fetch algorithm (Step 5.1). Details of the steps need to be discussed (see below).

whatwg/fetch#1225 is the tracking issue for the Fetch standard changes.

Topics to discuss

The following topics should be discussed as next steps if the above proposal makes sense.

• Processing Link headers in Early Hints. This could be similar to 4.2.4.4 Processing Link headers but the processing model isn't well defined (Link header processing not defined #4224)
• CSP
• Cross origin policies integration (COEP, CORP)
• Network partition keys / HTTP cache partitions

cc/ @yutakahirano @yoavweiss (Please cc relevant people)

@annevk: What do you think?

[yoavweiss]

/cc @noamr

[yutakahirano]

cc: @ddragana

[annevk]

I think overall this sounds reasonable. I think the tricky bit is figuring out the policy container to be used for any fetches resulting from the 103. How will we deal with CSP, referrer, sandboxing, etc.

Another challenge here is that currently Fetch is handed a "client" which doesn't really work for this. (Arguably that setup needs some changes anyway as Fetch needs to pull of what it needs before it goes in parallel and I'm not sure it does for everything.)

[noamr]

I think overall this sounds reasonable. I think the tricky bit is figuring out the policy container to be used for any fetches resulting from the 103. How will we deal with CSP, referrer, sandboxing, etc.

Another challenge here is that currently Fetch is handed a "client" which doesn't really work for this. (Arguably that setup needs some changes anyway as Fetch needs to pull of what it needs before it goes in parallel and I'm not sure it does for everything.)

Conceptually, I suggest that a 103 would be somewhat equivalent to a prefetch by a document from the same origin as the navigation (which is also yet to be fully specified.

Something like:

• A 103 response arrives
• For the first 103, create a fake prefetching document with the URL of the response
• Assign to that document the CSP known so far, e.g. CSP received by this or other 103 responses
• Once the real document is created and initialized, apply the headers again as if they were regular link headers.

(... not sure if the spec needs to involve this fake document in practice, but I'm suggesting it should behave in an equivalent manner)

[noamr]

Thinking about this more, I believe we are going to need that fake document and environment settings object, which would resolve some fetch-related questions.

[noamr]

Another challenge here is that currently Fetch is handed a "client" which doesn't really work for this. (Arguably that setup needs some changes anyway as Fetch needs to pull of what it needs before it goes in parallel and I'm not sure it does for everything.)

I think our friends here are creating a policy container from a fetch response and reserved client. We might not need a fake document if we piggy back on those.