Re: Comments on httpbis-client-hints-01

On Wed, Jun 1, 2016 at 3:46 PM, Vasiliy Faronov <> wrote:

> This "all subsequent requests" is obviously intended to be qualified
> somehow. It's not "all requests to all servers ever", is it? Should it
> be "all subsequent requests to the same origin"? Should it be "all
> subsequent requests to this resource"?
> Likewise, the "SHOULD append" phrase is unclear: append to what exactly?

We have a related open bug on GitHub, let's merge this discussion there:

On Thu, Jun 2, 2016 at 5:29 PM, Amos Jeffries <> wrote:

> If the response is influenced by a header, then it needs to ('SHOULD')
> be listed.
> There is a case where some combination of the listed header values
> results in a server actually not considerng the DPR at all for that
> response. This shows up worst with Apache in the way its modules are
> designed.
> However, this is kind for coped with by the caches considering any
> slight variation of the listed headers as a non-match for the specific
> response(s) that exact Vary was handed back on. If a different set of
> values for those same headers results in a DPR being added to the list
> the cache has to alter its stored key and the previous set of variants
> is "lost".
> The "lost" factor leads to annoying headaches so best interoperability
> would be to always list it. But the ecosystem can still cope with
> servers that are not able to for some reason.

Makes sense, thanks Amos.

s/which hints were used/which hints may affect the selected response/

Does that look reasonable?

On Fri, Jun 3, 2016 at 5:11 AM, Vasiliy Faronov <> wrote:

> On Fri, Jun 3, 2016 at 2:55 PM, Julian Reschke
> <> wrote:
> > What would *you* want the spec to say? Just be silent about it? Or
> declare
> > invalid therefore "must ignore"?
> Just be silent about it. Just as with other non-critical header
> fields, such as User-Agent.

Define non-critical? Sadly, UA header is often used to make guesses about
client properties that then affect the selected response. One of the goals
of CH is to eliminate the need for such hacks and make this process

I think we should keep the current language.

Received on Friday, 3 June 2016 18:08:58 UTC