Subject: Re: Variants and Client Hints

From: Leif Hedstrom <[email-masked]>
Date: Tue, 10 Jul 2018 10:31:59 -0600

> On Jun 12, 2018, at 11:27 PM, Mark Nottingham <[email-masked]> wrote:
> 
> 
>>> That said, the syntax of Variant-Key now allows a response to match multiple keys, which at least helps in the duplication issue; see the last part of:
>>>  https://httpwg.org/http-extensions/draft-ietf-httpbis-variants.html#variant-key
>> 
>> I agree that's better, but still, the response for `DPR: 2, Viewport: 300`, `DPR:1, Viewport: 600` and `DPR: 2, Viewport: 600, Save-Data: on` could be one and the same. Avoiding that cache duplication can be an important factor.
> 
> 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?

Cheers,

— Leif

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 11 Jul 2018 13:57:43 +1000

> On 11 Jul 2018, at 2:31 am, Leif Hedstrom <[email-masked]> wrote:
> 

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

Also, note that the form at the top (in the first example) is already in the spec; are you pushing back on that? It also has the capability to assign multiple keys to a single response, just in a more limited way.

Personally, I like the second form; it seems like a good balance between complexity and the capabilities that people have been repeatedly asking for here.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Leif Hedstrom <[email-masked]>
Date: Wed, 11 Jul 2018 09:56:46 -0600

> On Jul 10, 2018, at 9:57 PM, Mark Nottingham <[email-masked]> wrote:
> 
> 
> 

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?

> Also, note that the form at the top (in the first example) is already in the spec; are you pushing back on that? It also has the capability to assign multiple keys to a single response, just in a m…

No, not pushing back on anything. Just concerned that we’re making things more complex, and potentially expensive on the server. :-).

> Personally, I like the second form; it seems like a good balance between complexity and the capabilities that people have been repeatedly asking for here.

Fair enough. I see that there’s a session in Montreal covering this topic, maybe that’s a good time for clarifications?

Cheers,

— Leif

---

From: Leif Hedstrom <[email-masked]>
Date: Wed, 11 Jul 2018 13:23:13 -0600

> On Jul 11, 2018, at 9:56 AM, Leif Hedstrom <[email-masked]> wrote:
> 
> 
> 

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

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 14 Jul 2018 12:52:07 -0400

> On 11 Jul 2018, at 11:56 am, Leif Hedstrom <[email-masked]> wrote:
> 
> 
> 

Well, sort of. Currently, the cache uses the variants header compute a list of candidate keys, sorted in order of preference. Those candidates are then matched with the keys in Variant-Keys. The cache is encouraged to choose the most preferred key, but isn't required to.

> And what if a response comes back with 10,000 secondary keys. We let it do that?

I'm sure we can put some sane limits on it, and a cache isn't required to support that many in any case.

> What if they overlap with other objects primary cache key? Is that an issue?

I'm not sure what you mean here; can you give an example?

> Fair enough. I see that there’s a session in Montreal covering this topic, maybe that’s a good time for clarifications?

Yep.

---

From: Yoav Weiss <[email-masked]>
Date: Mon, 16 Jul 2018 11:49:04 +0200

On Wed, Jun 13, 2018 at 7:27 AM Mark Nottingham <[email-masked]> wrote:

>
>
> > On 8 Jun 2018, at 11:33 am, Yoav Weiss <[email-masked]> wrote:
> >
> > On Fri, Jun 8, 2018 at 11:12 AM Mark Nottingham <[email-masked]> wrote:
> >> Hi Yoav,
> >>
> >> On 8 Jun 2018, at 10:55 am, Yoav Weiss <[email-masked]> wrote:
> >>
> >> For example, let's say that we say the rule here is "next smallest." A
> server that prefers quality can take that into account and up the quality
> of their images, relative to the sizes they make available. If they want to
> go back to the origin, they won't use Variants; they'll fall back to Vary.
> >
> > High quality but upscaled images will end up upsetting everyone (as
> they'd end up blurry and bloated).
> >
> > The inverse (i.e. a "next largest" algorithm) might be a better choice,
> but I suspect it won't satisfy some people's use cases.
>
> Hm. A little more?
>
> >> I don't think adding more complexity to the protocol is justified here;
> people can meet their use cases (at least as far as you outline above) with
> just one algorithm.
> >
> > I'm not sure I see how. Could you outline an example?
>
> See below.
>
> >> My thinking to date has been that extra information of this sort could
> be encoded in the available-value if necessary -- but it'd be nice to have
> a worked example. Note that the syntax of available-value opened up in the
> latest draft; if more characters would help, we can figure that out.
> >
> > Are you suggesting that origins will communicate in the available-value
> e.g. the ranges of viewports that an image can satisfy? That may work if we
> ignore the potential cross-conneg-mechanism interactions.
>
> That's one possibility, At the end of the day, available-value is just a
> string under control of the spec, and the algorithm can do pretty much
> anything as long as it produces appropriate outputs (although if it relies
> on inputs not listed, it's going to raise the bar for implementation). The
> tricky bit is likely to be making it succinct.
>
>
> >> That said, the syntax of Variant-Key now allows a response to match
> multiple keys, which at least helps in the duplication issue; see the last
> part of:
> >>
> > I agree that's better, but still, the response for `DPR: 2, Viewport:
> 300`, `DPR:1, Viewport: 600` and `DPR: 2, Viewport: 600, Save-Data: on`
> could be one and the same. Avoiding that cache duplication can be an
> important factor.
>
> 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.,
>

I like the expressiveness that second syntax enables.

Just to clarify: when processing the keys, we're not relying on ordering,
but on the values declared as potential variants, right?

If so, I can see cases where the variants values may have collisions (e.g.
if `Save-Data` were defined as "0" and "1" values, it would collide with
DPR). At the same time, I'm not sure this will be a problem in practice,
and we can probably avoid it becoming a problem by being careful about
future client hint values and their interactions with existing ones.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 19 Jul 2018 13:39:54 -0400

On 16 Jul 2018, at 5:49 am, Yoav Weiss <[email-masked]> wrote:
> Just to clarify: when processing the keys, we're not relying on ordering, but on the values declared as potential variants, right?

Here, within each variant-key value (separated by ","), the parameters (separated by ";") need to be ordered in the same way that Variants are. So in the first key above, "2" refers to DPR, "300" refers to Viewport, and "off" refers to Save-Data.

In the meeting, we also mentioned that the ordering of the variant-key values themselves was important; the first one indicates *this* response's key (to allow simpler implementations to ignore the other keys).

What do you mean by "the values declared as potential variants"?

> If so, I can see cases where the variants values may have collisions (e.g. if `Save-Data` were defined as "0" and "1" values, it would collide with DPR). At the same time, I'm not sure this will be a problem in practice, and we can probably avoid it becoming a problem by being careful about future client hint values and their interactions with existing ones.