W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: Variants and Client Hints

From: Ilya Grigorik <igrigorik@google.com>
Date: Wed, 6 Jun 2018 11:14:38 -0700
Message-ID: <CADXXVKrFBeLJW=Mh70S1bzQct-X440Km_kkacefKE=PwpCsYhg@mail.gmail.com>
To: "Mark Nottingham (Google Drive)" <mnot@mnot.net>, Yoav Weiss <yoav@yoav.ws>
Cc: Jeffrey Yasskin <jyasskin@google.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
+Yoav Weiss <yoav@yoav.ws>

On Mon, Jun 4, 2018 at 5:31 AM Mark Nottingham <mnot@mnot.net> wrote:

> Hi Jeffrey,
>
> > On 2 Jun 2018, at 1:21 am, Jeffrey Yasskin <jyasskin@google.com> wrote:
> >
> > Hey Mark,
> >
> > I'm working on a matching algorithm for bundled exchanges (
> https://github.com/WICG/webpackage/issues/201), and I realized that a
> CDN's use of variants will need a similar algorithm.
> https://httpwg.org/http-extensions/draft-ietf-httpbis-variants.html#cache
> is fairly clear about how to pick a "best" Variant-Key for the Accept-*
> headers, but the introduction also mentions Client Hints, where matching is
> less about string equality.
> >
> > For example, if the client sends Viewport-Width: 350, and the server has
> images that are ideal for Viewport-Widths of 320 or 400, which one gets
> sent? I can imagine a couple options:
> >       • Only certain kinds of clients are supported efficiently. 🤢
>

Can you elaborate on why this would be the case and what your definition of
"efficiently" is?


> >       • 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.
Received on Wednesday, 6 June 2018 18:15:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:21 UTC