W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2020

Client Hint Reliability

From: David Benjamin <davidben@chromium.org>
Date: Mon, 20 Jul 2020 13:35:57 -0400
Message-ID: <CAF8qwaD0CZkLJR87BeGepjQ5Asee6Aiu9qnoXq3kK28RY2Z48w@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
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:
https://github.com/WICG/client-hints-infrastructure/issues/16

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:
https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability-00

There’s also an overview in W3C-style explainer
<https://w3ctag.github.io/explainers> form in the Client Hints
infrastructure WICG repo:
https://github.com/WICG/client-hints-infrastructure/blob/master/reliability.md

I would be interested in hearing the WG’s thoughts on this.

David
Received on Monday, 20 July 2020 17:36:27 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 July 2020 17:36:28 UTC