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

From: Ilya Grigorik <[email-masked]>
Date: Wed, 2 Sep 2015 09:51:14 -0700

On Mon, Aug 31, 2015 at 12:00 AM, Mark Nottingham <[email-masked]> 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

---

From: Leif Hedstrom <[email-masked]>
Date: Wed, 2 Sep 2015 15:32:55 -0600

> On Sep 2, 2015, at 10:51 AM, Ilya Grigorik <[email-masked]> wrote:
> 
> 
> On Mon, Aug 31, 2015 at 12:00 AM, Mark Nottingham <[email-masked] <mailto:[email-masked]>> wrote:
> https://developers.google.com/web/updates/2015/09/automating-resource-selection-with-client-hints <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

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

---

From: Yoav Weiss <[email-masked]>
Date: Fri, 4 Sep 2015 09:28:40 +0200

On Wed, Sep 2, 2015 at 11:32 PM, Leif Hedstrom <[email-masked]> wrote:

> 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
>

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
>
>