Allow servers to specify max-age in the client hints header

[tarunban]

The Accept-CH header is currently included by origin servers in HTTP responses if they are interested in receiving client hints from the browser (e.g., DPR). The spec currently does not require browsers to persist the opt-in across browser restarts. This means that if the origins are interested in receiving hints on all requests, then they need to include the Accept-CH header on all responses. This has two disadvantages: (i) Browsers currently fail to include the hints on the first request after the browser restart; and, (ii) It may not be possible for the origin servers to include the Accept-CH header on all responses due to responses being served out of different endpoints (CDNs etc.).

To fix this: The Accept-CH header should also support a max-age header value which indicates for how long should the browser remember this opt-in (including across browser restarts). A value of max-age set to 0 should cause the browser to stop sending client-hints to the origin. As an example,

Accept-CH: feature1, feature2, max-age=86400

would imply that the browser should include hints feature1 and feature2 for next 86400 seconds for that origin.

[mnot]

This is basically defining a separate cache from the HTTP cache, which has significant implementation overhead, and it appears you're scoping it to the entire origin, rather than just the response. These things are possible, but it's a pretty big change.

My understanding was that the common use case for client hints is for subresources, where having Accept-CH for the initial page load doesn't matter; i.e., you get Accept-CH on the HTML load, and then send the various hints on the subresource requests. What's your use case here?

P.S. Accept-CH is being defined over at https://github.com/httpwg/http-extensions, so if you want to extend it, you should really discuss it over there.

[tarunban]

@mnot Thanks!. I have filed httpwg/http-extensions#306, so I am going to close this bug. We can continue the discussion there, but I was under the impression that hints were not explicitly restricted to subresources, and browsers could include hints on the next HTML (aka main frame / navigation) requests too.

The real use case here is that content providers are interested in receiving hints on the HTML (aka main frame) requests so they can accordingly adapt the content of the HTML (e.g., URLs of subresources).