Re: Variants and Client Hints

On Fri, Jun 8, 2018 at 11:12 AM Mark Nottingham <mnot@mnot.net> wrote:

> Hi Yoav,
>
> On 8 Jun 2018, at 10:55 am, Yoav Weiss <yoav@yoav.ws> wrote:
> >
> > If we go back to Jeffrey's example, there are a few possible answers
> that are all valid:
> > * Pick the smaller image (so 320 in the example) - that could be a
> preference for servers which prefer data saving at the expense of image
> quality.
> > * Pick the larger image (so 400) - a legitimate preference for a service
> which prefers quality
> > * None (and go back to origin) - a service that wants to serve pixel
> perfect images, which only the origin (or upper layer cache) can produce
> >
> > Since there are several legitimate choices here, it doesn't make sense
> to arbitrarily codify one of them in the RFC.
>
> For this specific case, I'm going to push back here. Keeping in mind that
> the whole point here of CH is to support multiple image quality "buckets"
> and find the closest match in the available buckets, is it really the case
> that such fine-grained control is necessary?
>
> 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.


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


>
> > It also doesn't make sense to delegate that decision to an intermediate
> cache which may not have direct relationship with the content. (managed by
> That Other Team™, shared between different parts of the site with different
> requirements, etc)
>
> Of course.
>
> > Maybe we need a signal header (`Variants-Choice`?) that can inform the
> algorithm of the content's preference?
>
> 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.


>
> >
> > To make matters even more complex, multiple client hints preferences can
> and should interact with those calculations and influence them (DPR, Width,
> save-data & ECT all come to mind).
> > The server can consider them more variants of stored responses, but
> there may be (many) duplicates in terms of content (e.g. viewport 350 +
> save data can return the same response as viewport 300 without save data.
> Same goes for DPR and all the rest)
> >
> > Would it be possible to somehow define all the client hints headers as a
> single content negotiation mechanism that takes all those values into
> account?
>
> This feels a lot like this discussion that came up in Key:
>   https://github.com/httpwg/http-extensions/issues/104
>
> I.e., high fidelity to the server's intent comes at the cost of
> considerable complexity.
>

I agree this keeps coming up, but doesn't mean that there's no need for it
:)


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


> > P.S. The spec says that con-neg mechanisms should start with `Accept-`,
> but CH doesn't conform to that (and it's probably a bit late to change at
> this point...)
>
> Yep. That's why it's a SHOULD.
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>