Re: Variants and Client Hints

> On Jul 11, 2018, at 9:56 AM, Leif Hedstrom <leif@ogre.com> wrote:
> 
> 
> 
>> On Jul 10, 2018, at 9:57 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> 
>> 
>> 
>>> On 11 Jul 2018, at 2:31 am, Leif Hedstrom <leif@ogre.com> wrote:
>>> 
>>>> Right, but that response would have on it something like:
>>>> 
>>>> Variants: DPR;1;2, Viewport;600;1200, Save-Data;on;off
>>>> Variant-Key: 1;2, 600, on;off
>>>> 
>>>> If that's not expressive enough, maybe we should be talking about a Variant-Key syntax that lets you specify alternative sets of values, e.g.,
>>>> 
>>>> Variants: DPR;1;2, Viewport;300;600, Save-Data;on;off
>>>> Variant-Key: 2;300;off, 1;600;off, 2;600;on
>>> 
>>> This seems rather convoluted, almost aching to the complexity of the old “Key” draft. And now instead of having one secondary cache key, I might have 3 (or <n>) that I must look up? I agree that deduping in the cache is admirable, but perhaps that is an implementation detail for the caches or services?
>> 
>> I'm not sure that's the right characterisation; it lets you register this response for three different keys; i.e., you don't have to look for three different things on each request, you just have to do one lookup and find the appropriate key (which might be any of these three).
> 
> 
> Assuming the request only satisfies one of those secondary cache keys, right? Is it possible / allowed that a request could match multiple of these Variant-Keys?
> 
> And what if a response comes back with 10,000 secondary keys. We let it do that? What if they overlap with other objects primary cache key? Is that an issue?


Replying to myself :). Yeh, I guess it’s somewhat implementation specific, but it’d be up to the server to make sure there’s no collisions on the secondary cache key across different primary cache keys.

Ciao,

— Leif

Received on Wednesday, 11 July 2018 19:23:49 UTC