W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

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

From: Ilya Grigorik <igrigorik@gmail.com>
Date: Fri, 7 Oct 2016 11:43:07 -0700
Message-ID: <CAKRe7JH7mpx4LHuwgTZDRm-gprkHd+t1rZ7TWxEHKfLowPi6PQ@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Fri, Oct 7, 2016 at 4:47 AM, Julian Reschke <julian.reschke@gmx.de>
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?
>

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 :-)
Received on Friday, 7 October 2016 18:44:18 UTC

This archive was generated by hypermail 2.3.1 : Friday, 7 October 2016 18:44:21 UTC