Re: Client Hints Reliability Drafts

Hi Lucas,


Thanks for the feedback, are you talking about the use of a SETTINGS frame
to deliver client hints preferences? The draft acknowledges the potential
issue: as you mentioned, delivering SETTINGS within the application layer
can be problematic, as they may arrive after other application data. This
forces the application to assume that peer settings are not always
available.

The draft suggests sending the ACCEPT_CH frame as early as possible. One
option I suggest is to include the ACCEPT_CH frame in Victor Vasiliev's
ALPS draft (https://datatracker.ietf.org/doc/html/draft-vvv-tls-alps-01)
when using TLS. This ensures that the settings are available to the
application as soon as the handshake completes, and that the information is
available to the user agent when it makes the first request.
I was thinking this topic could be discussed in the TLS group when we
explore the details related to ALPS. It seems over complicated when
Involving too many drafts in both the TLS and HTTP groups at the same time.

Regards,
Victor

On Tue, Feb 25, 2025 at 2:33 PM Lucas Pardue <lucas@lucaspardue.com> wrote:

> 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*
> <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/*
> <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/*
> <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
>
>
>
>