Metadata to indicate if fetch was instigated as a result of 103 early hints

[LPardue]

103 Early hints is seeing increased deployment and usage on the Internet.

A server that sends too many hints is sub-optimal. A client has discretion about what hints it chooses to use and subsequently issue request for. From an observability perspective, it is difficult for operators to gain insight into whether a fetch was instigated directly because of an early hint, or for some other reason. That information could be used to tailor the set of hints.

The proposal therefore is to add a new indicator about whether a request is made due to early hints or not. This could be e.g. Sec-Fetch-Early-Hint: ?1, or some other format.

[arturjanc]

I wonder if it would make sense to use Sec-Fetch-Mode for that, e.g. Sec-Fetch-Mode: early-hint. If not, a separate header seems reasonable.

[LPardue]

Yeah thats a possibility, although the fact an early hint might have caused a fetch seems complimentary to the fetch mode? Not an expert on this though

[bashi]

Fetch mode of requests initiated by an early hints response can be same-origin, cors or no-cors, or even navigate if a client supports prefetch, so using Sec-Fetch-Mode may not be appropriate.

A request has an associated initiator type, the value of which is supposed to be 'early-hints' when the request was initiated by a 103 response. An option might be to expose it as Sec-Fetch-Initiator-Type, however, the definition of initiator type (and initiator) is somewhat ambigueous so I'm not sure that's a good idea. @yoavweiss

There is also discussion about whether we should include both initiator and destination.

[LPardue]

Oh, if initiator type of early hints was available via the Resource Timing API then that would probably work too https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-initiatortype

[arturjanc]

My guess is that if integrating with Resource Timing addresses this use case it might be a better solution because it avoids bytes to every network request. Otherwise, exposing the initiator type as Sec-Fetch-Initiator-Type seems okay, but given the overlap with destination, which all browsers are already sending (Sec-Fetch-Dest) it would result in a fair amount of duplication (and be somewhat confusing for developers).

[tunetheweb]

I think it’s already exposed to ResourceTiming though IIRC there might be a bug with Chrome’s implementation of that.

I think @LPardue wants visibility from the server side though agree that does potentially create duplication.

[LPardue]

I could probably live Resource Timing but from w3c/resource-timing#273 it seems there is no WPT to check whether it works or not? What would be the best way to look into that?

[tunetheweb]

I think this is the test: https://wpt.fyi/results/loading/early-hints/preload-initiator-type.h2.window.html?aligned
Which suggests Chrome does set this, so I might have been wrong with my comment above!

And here's for the experimental version: https://wpt.fyi/results/loading/early-hints/preload-initiator-type.h2.window.html?label=experimental&label=master&aligned where you can see Firefox also sets this when Early Hints is enabled. Which is weird as thought they only supported preconnect for Early hints...

[tunetheweb]

FYI just tested it in Chrome and 115 and it is set correctly:

[yoavweiss]

Should we close this? It seems like RT addresses the use case