Subject: draft-ietf-httpbis-client-hints-02, "2.2.1 Advertising Support for Client Hints"

From: Julian Reschke <[email-masked]>
Date: Fri, 7 Oct 2016 13:47:36 +0200

<https://greenbytes.de/tech/webdav/draft-ietf-httpbis-client-hints-02.html#rfc.section.2.2.1>:

"Servers can advertise support for Client Hints using the Accept-CH 
header field or an equivalent HTML meta element with http-equiv 
attribute ([W3C.REC-html5-20141028])."

The HTML spec asks for extensions to be registered in 
<https://wiki.whatwg.org/wiki/PragmaExtensions>, but apparently that 
hasn't happened yet.

"When a client receives Accept-CH, or if it is capable of processing the 
HTML response and finds an equivalent HTML meta element, it SHOULD 
append the Client-Hint header fields that match the advertised 
field-values to the header list of all subsequent requests. For example, 
based on Accept-CH example above, a user agent could append DPR, Width, 
Viewport-Width, and Downlink header fields to all subresource requests 
initiated by the page constructed from the response. Alternatively, a 
client can treat advertised support as a persistent origin preference 
and append same header fields on all future requests initiated to and by 
the resources associated with that origin."

The "SHOULD" IMHO is problematic, as it isn't clear from the following 
text to what URIs it applies? All of the same origin? Only the same 
resource? Subresources?

Best regards, Julian

---

From: Ilya Grigorik <[email-masked]>
Date: Fri, 7 Oct 2016 11:43:07 -0700

On Fri, Oct 7, 2016 at 4:47 AM, Julian Reschke <[email-masked]>
wrote:

> HTML response and finds an equivalent HTML meta element, it SHOULD append
> the Client-Hint header fields that match the advertised field-values to the
> header list of all subsequent requests. For example, based on Accept-CH
> example above, a user agent could append DPR, Width, Viewport-Width, and
> Downlink header fields to all subresource requests initiated by the page
> constructed from the response. Alternatively, a client can treat advertised
> support as a persistent origin preference and append same header fields on
> all future requests initiated to and by the resources associated with that
> origin."
>

It was left intentionally vague to allow for flexibility as different
UAs/clients experiment with how and when to send these hints. Some
additional context here:
https://greenbytes.de/tech/webdav/draft-ietf-httpbis-client-hints-02.html#security-considerations

Open to suggestions for how to word it better though :-)

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Oct 2016 15:20:40 +0200

On 2016-10-07 20:43, Ilya Grigorik wrote:
>
> On Fri, Oct 7, 2016 at 4:47 AM, Julian Reschke <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     "When a client receives Accept-CH, or if it is capable of processing
>     the HTML response and finds an equivalent HTML meta element, it
>     SHOULD append the Client-Hint header fields that match the
>     advertised field-values to the header list of all subsequent
>     requests. For example, based on Accept-CH example above, a user
>     agent could append DPR, Width, Viewport-Width, and Downlink header
>     fields to all subresource requests initiated by the page constructed
>     from the response. Alternatively, a client can treat advertised
>     support as a persistent origin preference and append same header
>     fields on all future requests initiated to and by the resources
>     associated with that origin."
>
>     The "SHOULD" IMHO is problematic, as it isn't clear from the
>     following text to what URIs it applies? All of the same origin? Only
>     the same resource? Subresources?
>
>
> additional context
> here: https://greenbytes.de/tech/webdav/draft-ietf-httpbis-client-hints-02.html#security-considerations
>

Well, we can't have a SHOULD without saying to what it applies to...

Maybe just say that getting Accept-CH for a URI implies that the server 
would like to see the listed client hints on all requests for 
subresources of that URI (with a proper definition of what that is), and 
then leave it at that.

Best regards, Julian

---

From: Ilya Grigorik <[email-masked]>
Date: Thu, 13 Oct 2016 08:26:15 -0700

On Thu, Oct 13, 2016 at 6:20 AM, Julian Reschke <[email-masked]>
wrote:

> would like to see the listed client hints on all requests for subresources
> of that URI (with a proper definition of what that is), and then leave it
> at that.
>

Sounds reasonable, will do.