Client Hints Reliability Drafts

Hello HTTP Working Group,

Client Hints(https://datatracker.ietf.org/doc/html/rfc8942) are a useful
mechanism that allows servers to advertise a set of request headers for
proactive content negotiation, which helps user agents send request headers
only when needed, reducing performance overhead and minimizing passive
fingerprinting. However, on the first HTTP request to a server, the user
agent hasn't received the server's preferences. This means that the first
request to a site might be missing critical client hints. This "first
request issue" can cause a range of problems, particularly when subsequent
requests within the same page do have accurate Client Hints. Here are some
key user-cases:

One of the scenarios is to deliver more relevant content to users. For
example, sites can use client hints (data about the user's browser, OS,
etc.) to deliver more relevant content and improve telemetry. Examples
include providing OS-specific help content,  the correct software installer
and right color scheme. When these hints are unavailable (due to browser
implementation choices, or lack of critical Client Hints ), websites face
difficult choices regarding user experience, this can cause increased
initial navigation time, and degraded initial experience and inconsistent
Behavior within the same page.

Another scenario is resolving issues related to inaccurate detection and
statistics. A website might use a spam detection system that relies on
client hints e.g. (platform version, OS, etc) to identify the traffic
trends or block suspicious requests. Since the first request might lack
critical Client Hints, the tracking or detection system could fail to
identify or properly categorize the request. This could lead to incorrectly
estimating traffic patterns, legitimate requests being mistakenly flagged
as spam and malicious requests marked as "normal”.

Given the benefits of Client Hints on improving performance, explicitly
server opt-in solutions, and minimizing fingerprints,  a reliable delivery
mechanism is needed to address the first HTTP requests problem as mentioned
above.  We propose two mechanisms to resolve this. The following two drafts
of Client Hints Reliability covers more details:

1) Critical-CH Header (
https://datatracker.ietf.org/doc/draft-victortan-httpbis-chr-critical-ch/ ):
An HTTP response header, Critical-CH, that allows the server to trigger a
client retry if needed.  However, from existing experience from lots of
sites, this option affects the rendering of the page which introduces page
load latency.


2) ACCEPT_CH Frame (
https://datatracker.ietf.org/doc/draft-victortan-httpbis-chr-accept-ch-frame/
): This is an HTTP/2 and HTTP/3 frame that delivers the server’s client
hints preferences. This mechanism can be implemented to avoid retries in
most cases, which is preferred for servers that have latency requirements.



These mechanisms make initial navigation time much more acceptable. Most
users would not experience performance degradation, and those who do could
improve their network setup to support the feature. This eliminates the
need for the more complex and potentially detrimental workarounds.

I’m trying to collect the latest feedback for the client hint delivery
mechanisms and am interested in hearing the WG’s thoughts.

Thanks,

Victor