Re: Call for Adoption: draft-grigorik-http-client-hints

On Wed, Sep 2, 2015 at 11:32 PM, Leif Hedstrom <leif@ogre.com> wrote:

>
> On Sep 2, 2015, at 10:51 AM, Ilya Grigorik <igrigorik@gmail.com> wrote:
>
>
> On Mon, Aug 31, 2015 at 12:00 AM, Mark Nottingham <mnot@mnot.net> wrote:
>
>> > There are probably other use-cases on the table I'm not aware of yet.
>> > I'm all ears.
>>
>> Any further thoughts after Ilya's mail?
>>
>
> FWIW, additional context on the use-case and motivation behind CH:
>
> https://developers.google.com/web/updates/2015/09/automating-resource-selection-with-client-hints
>
>
>
> I’m surprised that there’s not been more concerns raised from the
> intermediary / caches perspective, only Amos’ well written reply.
>
> First, I’m very happy to see the inclusion of the Key draft in here, which
> I think is much needed regardless of this proposal. But there’s a big can
> of worm with our existing Vary: headers and this proposal. I can’t speak
> for all caches, but the one I work on could have a real problem with e.g. a
> Vary: of
>
> Vary: DPR, Width, Downlink
>

FWIW, Downlink is currently not part of the implementation, which reduces a
lot of the potential variance.


>
>
> I know, I know, Cache <n> is better than ATS… We’ll improve ours of
> course, particularly if the Key draft happens. It’s just not particularly
> trivial, and requires access to a “most recently seen cacheable Key header”
> for a URL before doing the cache lookups. In our case, this probably will
> require two cache lookups as well (but too early to say), and a cache
> update if the Key header changes.
>
> This is nothing new introduced by CH of course. But CH could make the
> problem worse for caches with an explosion of objects from poorly
> normalized Vary: data.
>
> Cheers,
>
> — Leif
>
>