Re: Working Group Last Call: HTTP Client Hints

Yoav Weiss <> Mon, 24 February 2020 08:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 912BA3A0815 for <>; Mon, 24 Feb 2020 00:05:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OzDg0O6NoFcP for <>; Mon, 24 Feb 2020 00:05:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4D8D3A07FF for <>; Mon, 24 Feb 2020 00:05:32 -0800 (PST)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1j68gO-0005X6-HA for; Mon, 24 Feb 2020 08:01:40 +0000
Resent-Date: Mon, 24 Feb 2020 08:01:40 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1j68gJ-0005WF-9O for; Mon, 24 Feb 2020 08:01:35 +0000
Received: from ([2a00:1450:4864:20::231]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1j68gE-0002AB-Pe for; Mon, 24 Feb 2020 08:01:35 +0000
Received: by with SMTP id e18so8948743ljn.12 for <>; Mon, 24 Feb 2020 00:01:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OHYIljWizNatVDfqUzGFHDDuY54XwYMkX7OhckllllE=; b=UrNircg2duxzH8jGCAHiI7gNVYe85efBStG1uYdDHk9fp8aPR0d/58cyfOVCd4cNU9 XbzFpypbY06BAINFwChT4onreOXYQfHBFwjVXU+vaud25rNvup5QuOIsXk7Le0tbhfMx ZqrMdM4QDM5LeCj/y9FsUVJx+1FOFyWq3Fx4T1F28yRyLSJkJmPgSDWAkyMQp5a1v+nm GYTLgTW4HUeTL029a0INrpmFROJGOkQhKZW3LkLD57JyampHNjAuem5IhDosrnkyc0dh /NZ3np7rv/zofQiiltakwaRpG/1uv+Sb2braZLfe1cZuchJhv/EGnK3LaVHwAzRY4zdr 2tOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OHYIljWizNatVDfqUzGFHDDuY54XwYMkX7OhckllllE=; b=MRHx7kBDwbTjlJfLZ5WELi0kA9lQWgiY80XSzjpD24S11oaUgkZx3Cnwe95Im9BwOS uHBvY1tRec4zEV4ws6PnXUBqgq5RE5abQYenGodFpm32iS5aJCx3cWfe+3jiOXloxM3G VWVm2TRB6sTLPcANBJ/1WVXlAyRcWCnBBJfCQsdO+uMK7q9feQdD4MaRPJXHPpDNAH2K RTq0z4CoiIktfrp0xffXaBEEeKvu5wH81zGAxPdl7TCdhMHF9mFFFf4XuJsSccleSb8C U1Rks9dJTLYG4xVfo1ybbiyufQ+kLXicHOmODdkBts6/sL2u5IAJH5OUp44GRZoxHTYs WIIw==
X-Gm-Message-State: APjAAAX6xd/gaUgm59RTsx1DAoF7hcESqFVnvO4yFYT9mbLYwLl/zN2g Kcu6yrVL17qHLobQXKHIWA/a/eZHlaYRFcCKUtf4ow==
X-Google-Smtp-Source: APXvYqxn9EfmMwtCOlEbf+Ry6PfzvJhi1OuxU9EzySm4ewSvnZR+rxZkjIvAylbjQQ9iQSJU2j7fidQ2N2SuRiNwW0w=
X-Received: by 2002:a2e:8544:: with SMTP id u4mr29530962ljj.31.1582531278230; Mon, 24 Feb 2020 00:01:18 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Yoav Weiss <>
Date: Mon, 24 Feb 2020 09:01:02 +0100
Message-ID: <>
To: Julian Reschke <>
Cc: Mark Nottingham <>, HTTP Working Group <>, Tommy Pauly <>
Content-Type: multipart/alternative; boundary="000000000000af657d059f4dc6b4"
Received-SPF: pass client-ip=2a00:1450:4864:20::231;;
X-W3C-Hub-Spam-Status: No, score=-8.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1j68gE-0002AB-Pe 724c91eebaae735d0e74d55a59893a61
Subject: Re: Working Group Last Call: HTTP Client Hints
Archived-At: <>
X-Mailing-List: <> archive/latest/37378
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Thanks for your feedback, Julian!
I PRed the related changes at

On Sun, Feb 23, 2020 at 2:20 PM Julian Reschke <>

> On 18.02.2020 05:09, Mark Nottingham wrote:
> > ...
> Here's my feedback:
> Terminology: please use "header field" or "field" consistently.


> In Section 1:
>     well as dynamic user and client preferences.  Applications that want
>     to allow the server to optimize content delivery and user experience
>     based on such capabilities have, historically, had to rely on passive
>     identification (e.g., by matching User-Agent (Section 5.5.3 of
>     [RFC7231]) header field against an established database of client
>     signatures), used HTTP cookies and URL parameters, or use some
>     combination of these and similar mechanisms to enable ad hoc content
>     negotiation.
> Please add refernce to Cookie spec.

Sure. That would be a reference to or
I'm guessing the former, but preferred asking.

>     However, proactive content negotiation requires clients to send these
>     request headers prolifically.  This causes performance concerns
>     (because it creates "bloat" in requests), as well as privacy issues;
>     passively providing such information allows servers to silently
>     fingerprint the user agent.
> FWIW, it doesn't really *require* them to be send prolifically; it's
> just the easiest way to do so.
> If there was a requirement for that, *this* spec by definition couldn't
> exist.

Replaced it with "However, traditional proactive content negotiation
techniques often mean that clients send these request headers

>     This document defines the Client Hints infrastructure, a framework
>     that enables servers to opt-in to specific proactive content
>     negotiation features, which will enable them to adapt their content
>     accordingly.  However, it does not define any specific features that
>     will use that infrastructure.  Those features will be defined in
>     their respective specifications.
> It would be great if this could link to at least one example of those.

Linked to UA Client Hints.

> In 1.1.:
>     This document uses the Augmented Backus-Naur Form (ABNF) notation of
>     [RFC5234] with the list rule extension defined in [RFC7230],
>     Appendix B.  It includes by reference the DIGIT rule from [RFC5234]
>     and the OWS and field-name rules from [RFC7230].
> No, it doesn't.

Removed everything but the 5234 reference.

> In Section 2:
>     A Client Hint request header field is a HTTP header field that is
>     used by HTTP clients to indicate configuration data that can be used
>     by the server to select an appropriate response.  Each one conveys
>     client preferences that the server can use to adapt and optimize the
>     response.
> Is it really always "configuration data"?

Removed "configuration"

> 2.1.  Sending Client Hints
>     Clients control which Client Hints are sent in requests, based on
>     their default settings, user configuration, and server preferences.
>     The client and server can use an opt-in mechanism outlined below to
>     negotiate which fields should be sent to allow for efficient content
>     adaption, and optionally use additional mechanisms to negotiate
>     delegation policies that control access of third parties to same
>     fields.
>     Implementers should be aware of the passive fingerprinting
>     implications when implementing support for Client Hints, and follow
>     the considerations outlined in "Security Considerations" section of
>     this document.
> General comment: it seems to me that BCP14 keywords are uppercased
> somewhat randomly...

Renamed a few instances that were not meant to be used in the BCP14 keyword
sense, and capitalized others.

>     Implementers should be aware of the passive fingerprinting
>     implications when implementing support for Client Hints, and follow
>     the considerations outlined in "Security Considerations" section of
>     this document.
> Please make this a proper xml2rfc link...

Added a link.

> Section 3.:
>     Servers can advertise support for Client Hints using the mechnisms
>     described below.
> a) a/mechnisms/mechanisms/
> b) looks like a single mechanism to me, actually

Good catch, thanks!

> In 3.1:
>     The Accept-CH response header field or the equivalent HTML meta
>     element with http-equiv attribute ([HTML]) indicate server support
>     for particular hints indicated in its value.
> A more precise reference might be good here. The HTML spec is really big.

Sure! Added a section number. Not sure how to link directly to specific
anchors in other specs.

>     Accept-CH is a Structured Header [I-D.ietf-httpbis-header-structure].
>     Its value MUST be an sh-list (Section 3.1 of
>     [I-D.ietf-httpbis-header-structure]) whose members are tokens
>     (Section 3.7 of [I-D.ietf-httpbis-header-structure]).  Its ABNF is:
> There is no Section 3.7 there; maybe
> <
> >?


>       Accept-CH = sh-list
>     For example:
>       Accept-CH: Sec-CH-Example, Sec-CH-Example-2
>     When a client receives an HTTP response advertising support for
>     provided list of Clients Hints, it SHOULD process it as origin
>     ([RFC6454]) opt-in to receive Client Hint header fields advertised in
>     the field-value, for subsequent same-origin requests.
> RFC6454 appears as informative reference, but has a normative
> requirement referencing it.

Added a "!"

>     For example, based on the Accept-CH example above, which is received
>     in response to a user agent navigating to "", and
>     delivered over a secure transport: a user agent SHOULD persist an
>     Accept-CH preference bound to "" and use it for
>     user agent navigations to "" and any same-origin
>     resource requests initiated by the page constructed from the
>     navigation's response.  This preference SHOULD NOT extend to resource
>     requests initiated to "" from other origins.
> Don't put normative keywords into examples. The requirements are alreay
> defined earlier, right? For instance, say "will have to" instead of


> In 3.1.1:
> I'd make that Section 3.2.
> In 4.1:
>     o  Entropy
>        *  Exposing highly granular data may help identify users across
>           multiple requests to different origins.  Reducing the set of
>           field values that can be expressed, or restricting them to an
>           enumerated range where the advertised value is close but is not
>           an exact representation of the current value, can improve
>           privacy and reduce risk of linkability by ensuring that the
>           same value is sent by multiple users.
>     o  Sensitivity
>        *  The feature SHOULD NOT expose user sensitive information.  To
>           that end, information available to the application, but gated
>           behind specific user actions (e.g. a permission prompt or user
>           activation) SHOULD NOT be exposed as a Client Hint.
>     o  Change over time
>        *  The feature SHOULD NOT expose user information that changes
>           over time, unless the state change itself is also exposed (e.g.
>           through JavaScript callbacks).
> The list is structured a bit strange. Maybe make it a definition list.

Can you point to an example of what you mean by that?

> Appendix A.  Interaction with Variants Response Header Field
>     Client Hints may be combined with Variants response header field
>     [VARIANTS] to enable fine-grained control of the cache key for
>     improved cache efficiency.  Features that define Client Hints will
>     need to specify the related variants algorithms as described in
>     Section 6 of [VARIANTS].
> Unless we're planning to finish VARIANTS really soon, I'd drop this
> appendix.

mnot - thoughts?