Re: Client Hint Reliability

As a quick update, I've just uploaded draft-01 of the document. I've
matched draft-ietf-httpbis-client-hints in using "user agent" instead of
"client", and we've realized that the HTTP/2 frame didn't quite work right
with HTTP caching (by the time you've made a network connection, you've
already evaluated Vary and potentially conditionalized the request), so
it's now been reworked as a funny restart which I think mirrors Critical-CH
fairly nicely.


On Mon, Jul 20, 2020 at 1:35 PM David Benjamin <>

> Hi all,
> One of the bits of developer feedback we’ve gotten on Client Hints is the
> first view problem, or more generally the reliability problem:
> An HTTP request can only take into account previous HTTP responses’
> Accept-CH headers, which means the first resource request to a site, either
> overall or after a config change, may be missing Client Hints. Fixing this
> requires detecting the reason for the missing header, which is tricky for
> the server (maybe the client just never sends it), and costs a round-trip.
> This makes Client Hints unattractive for top-level resources, or use cases
> where the header meaningfully changes the page.
> We’ve been looking at a pair of mechanisms to address this. The first is
> an HTTP response header for the server to trigger a client retry if needed.
> The second builds on Victor Vasiliev’s ALPS drafts to get the information
> to the client before its first request in most cases, avoiding the
> performance hit.
> I’ve written up an initial draft describing the two:
> There’s also an overview in W3C-style explainer
> <> form in the Client Hints
> infrastructure WICG repo:
> I would be interested in hearing the WG’s thoughts on this.
> David

Received on Thursday, 27 August 2020 19:00:05 UTC