Re: Comments on httpbis-client-hints-01

On 2/06/2016 9:50 a.m., Ilya Grigorik wrote:
> Hi Vasiliy.
> Thanks for the feedback, here and on GitHub. WIP branch:
> On Tue, May 31, 2016 at 11:15 AM, Vasiliy Faronov wrote:
>> Hi,
>> A few comments on draft-ietf-httpbis-client-hints-01:
>> 1. It seems to imply that Vary only includes the hints that were
>> present in the request ("emit a Vary . . . to indicate which hints
>> were used"). But, for example, if the request had *no* DPR field, yet
>> the response *would* be influenced by a DPR field, shouldn't the
>> response still include "Vary: DPR"?Otherwise a cache cannot know that
>> a subsequent request with DPR must be written through to the origin
>> server.
> Good points, I think that makes sense. Any cache implementers / Vary
> experts want to chime in here? What's the best practice to handle this?

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

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.

>> 2. The Accept-CH field seems underspecified. Is it per-resource? (and
>> if so, doesn't it duplicate Vary?) Or is it per-origin? Or does it
>> just apply to resources linked from the response?
> If we're talking about browser as "client", then the behavior is specified
> in Fetch API:
> Does it duplicate Vary: no, I don't think so, they signal different things
> to the client and they don't have same implications for upstream caches.
>> 3. Are requirements like "If DPR occurs in a message more than once"
>> (ditto for the other fields) useful? Duplicating these fields is
>> already invalid per RFC 7230.
> Ah, happy drop those if they're no longer needed. Any objections?

The fact of being invalid is covered by 7230.

But how to handle these specific headers when invalid situations occur
is still needed in the more specific document.


Received on Friday, 3 June 2016 00:30:32 UTC