Re: Variants and Client Hints

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

> On 6 Jun 2018, at 8:14 pm, Ilya Grigorik <igrigorik@google.com> wrote:
> >
> > >       • The available-values are single numbers, and the spec says
> that a request for 350 matches the next smaller number.
> > This is kind of what I anticipated, but maybe Ilya has some thoughts?
> >
> > I think this is something we should defer to the implementers. Some
> sites have very stringent requirements about image quality and would not
> accept upscaling (e.g. think product images), whereas others might be open
> to it and might explicitly choose this route when save-data hint is present.
>
> In Variants, the definition of a particular content negotiation mechanism
> is responsible for defining the algorithm for selecting a result (or
> results); see <
> https://httpwg.org/http-extensions/draft-ietf-httpbis-variants.html#define>.
> Defering to the implementers would mean that each cache would behave
> differently, so no interop and content folks would be (justifiably) grumpy
> about this.
>
>
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. 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)
Maybe we need a signal header (`Variants-Choice`?) that can inform the
algorithm of the content's preference?

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?

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