Intent to Prototype: Client Hint Reliability: Critical-CH Header

227 views
Skip to first unread message

Aaron Tagliaboschi

unread,
Sep 9, 2020, 1:18:30 PM9/9/20
to blink-dev, Yoav Weiss

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:


  1. The client does not support that particular client hint, or client hints in general

  2. 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

  3. 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

aaro...@chromium.org, yoav...@chromium.org



Joe Medley

unread,
Sep 9, 2020, 2:32:10 PM9/9/20
to Aaron Tagliaboschi, blink-dev, Yoav Weiss
Aaron,

Thank you for submitting this. Can you please create a Chrome Status entry? (I have just verified that you have access to do that.)

Joe
Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.


--
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

unread,
Sep 9, 2020, 2:51:20 PM9/9/20
to Joe Medley, blink-dev, Yoav Weiss

Joe Medley

unread,
Sep 10, 2020, 11:35:56 AM9/10/20
to Aaron Tagliaboschi, blink-dev, Yoav Weiss
Thanks!

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.

Erik Anderson

unread,
Feb 9, 2021, 7:54:38 PMFeb 9
to aaro...@chromium.org, blin...@chromium.org, yoav...@chromium.org

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!

--

Reply all
Reply to author
Forward
0 new messages