Re: Variants and Client Hints

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.

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.

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

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

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


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

Received on Friday, 8 June 2018 09:13:19 UTC