Re: Client Hints Reliability Drafts

Hi Victor,

With regard to the ACCEPT_CH frame, when I surveyed client implementations during my response to HTTP/2 rapid reset, my findings were that none wait for SETTINGS frames before issuing requests that are queued up to go out on an connection being open. This is understandable from a client latency minimisation perspective, but annoying from a server perspective.

This interaction seems like a hard design problem for the protocols. And it's especially worse for an extension frame that may or may not be deployed. A client can't know if it should wait or not to learn some information. 

In something like WebTransport they've said the client must wait to learn the server settings. That's doesn't seem acceptable in this case, a design that is trying to optimise the bootstrap time of HTTP webpages.

So that leaves me sadly pessimistic of the deployment reality of these things.

Cheers
Lucas

On Tue, Feb 25, 2025, at 18:57, Victor Tan wrote:
> 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
> 
> 
>