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