Re: Variants and Client Hints

[Mark Nottingham <[e-mail]>]

> On 8 Jun 2018, at 11:33 am, Yoav Weiss <[e-mail]> wrote:
> 
> On Fri, Jun 8, 2018 at 11:12 AM Mark Nottingham <[e-mail]> wrote:
>> Hi Yoav,
>> 
>> On 8 Jun 2018, at 10:55 am, Yoav Weiss <[e-mail]> 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:
>>   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


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