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

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