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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 7 Oct 2016 13:47:36 +0200
To: ietf-http-wg@w3.org
Message-ID: <305711ec-3ef5-a2c3-7be4-aef2ded0d195@gmx.de>
<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
Received on Friday, 7 October 2016 11:48:04 UTC

This archive was generated by hypermail 2.3.1 : Friday, 7 October 2016 11:48:06 UTC