Intent to Prototype: Client Hint Reliability: Critical-CH Header
Aaron Tagliaboschi
TAG Review: https://github.com/w3ctag/design-reviews/issues/549
Explainer
https://github.com/WICG/client-hints-infrastructure/blob/master/reliability.md
This feature is part of a larger reliability story; the related section can be found here.
Summary
This feature will add support for a new HTTP response header Critical-CH to indicate that if a particular Client Hint header was not received and could have been sent, a new request should be made that includes the particular Client Hint header.
Motivation
Some Client Hints are optimizations, while others meaningfully change the page. For example, a site may use Device-Memory to serve simple and complex variants, and Viewport-Width for a server-side rendering optimization. If only the first request lacks Device-Memory, the site will jarringly switch versions between page loads. The server could try to detect this and self-redirect, but this will loop if the client declined to send the hint, or simply didn’t implement it.
With the current Client Hint spec and implementation, a client hint could be not sent to a server for any one of a few reasons:
The client does not support that particular client hint, or client hints in general
The client was unaware of the site’s most recent preferences, either because the client has never been to this site or because the preferences have been changed since the last visit
The client opts to not send a particular set of client hints for whatever reason
Situation 2 can simply be fixed by waiting for the next request or triggering it via a redirect when a hint is not received. However, doing so in situations 1 and 3 would lead to an infinite loop. Fixing this would require adding an inordinate amount of state and extra logic. Instead, it would be better for the developer for this logic to be maintained client-side.
The basic algorithm client-side is this:
If, after processing the Accept-CH response header, the client would have sent a critical hint (listed in the Critical-CH response header) not sent with the request, it stores the new client hint preferences how it normally would and retries the request. Otherwise, it uses the response as-is.
See the explainer for examples.
Risks
Compatibility
This change is a no-op for servers that don’t send the Critical-CH response header, and shouldn’t pose a compatibility risk for older browsers or browsers that don’t support the header. This feature still allows for the possibility of lack of support from the browser side, which means that sites shouldn’t need to treat other browsers any differently if they do or don’t support it.
Interoperability
There’s generally neutral feelings for Client Hints and the related proposals from other browser vendors. Safari is generally neutral without an official stance and Firefox maintains a “non-harmful” position on Client Hints and UA Client Hints. Edge, however, has been publicly supportive.
There have also been positive signals from other browsers about the potential impacts of the UA Client Hints proposal.
Web Developer signals
Part of the web dev reaction to User-Agent Client Hints efforts was concern about not having certain hints on first navigation. The Critical-CH response header aims to fix this issue at the cost of a request/response round trip, and the other part of the proposal aims to remove that round trip in most cases.
Ergonomics
Utilizing the Critical CH response header will mean more request/response round trips, especially on first-time navigations to the site and after a change in Client Hint preferences. It is up to the developer to decide if the need for the information on the first navigation request is worth “paying” the cost of extra requests.
It should be noted that, unless the majority of a site's traffic is first-time navigations, a retry should be relatively rare. The lifetime of client hint preferences is browser session, which is generally fairly long lived.
Much of these situations will be resolved by the other side of the larger Client Hint Reliability proposal, which puts the client hint negotiation into the HTTP/2, HTTP/3, and TLS handshakes, before the first navigation.
Activation
This feature was designed to be low-friction for developers. Like the Accept-CH response header, this can be a simple static configuration in HTTP server software and sent with all responses.
Debuggability
The secondary request and response should be visible in DevTools. I don’t think there will need to be any active work.
Platforms
Supported
Desktop - All
Chrome OS
Android
Not Supported
Android WebView - Client Hints are not fully supported yet.
Contacts
Joe Medley
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJwB4Xa7qfk7w9ZWbhixpi2aT4YN3JRVgbDM-nCK4pQZW10H8w%40mail.gmail.com.
Aaron Tagliaboschi
Joe Medley
Erik Anderson
The Microsoft Edge team is very supportive of this feature.
We share the general concern about site owners unintentionally introducing redirect loops, particularly if a browser chooses not to expose the info (perhaps a global- or user-based decision or because of some future privacy budget-like constraint) or hasn’t implemented a specific hint yet. This feature will help sites avoid such mistakes and should help them remain compatible with a broad range of future browsers and browser configurations.
p.s. I realize this is a fairly old thread. Sorry for not publicly expressing support sooner!
--