Re: Variants and Client Hints
Yoav Weiss <yoav@yoav.ws> Fri, 08 June 2018 09:42 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDE6130E50 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 8 Jun 2018 02:42:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.661
X-Spam-Level:
X-Spam-Status: No, score=-7.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yoav-ws.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngUQiQaYGG5m for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 8 Jun 2018 02:42:03 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47AE512F18C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 8 Jun 2018 02:42:03 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1fRDmk-0000L3-Gn for ietf-http-wg-dist@listhub.w3.org; Fri, 08 Jun 2018 09:34:18 +0000
Resent-Date: Fri, 08 Jun 2018 09:34:18 +0000
Resent-Message-Id: <E1fRDmk-0000L3-Gn@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <yoav@yoav.ws>) id 1fRDma-0000KH-Ux for ietf-http-wg@listhub.w3.org; Fri, 08 Jun 2018 09:34:08 +0000
Received: from mail-wr0-f173.google.com ([209.85.128.173]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <yoav@yoav.ws>) id 1fRDmW-0004Ao-4g for ietf-http-wg@w3.org; Fri, 08 Jun 2018 09:34:08 +0000
Received: by mail-wr0-f173.google.com with SMTP id w10-v6so12661579wrk.9 for <ietf-http-wg@w3.org>; Fri, 08 Jun 2018 02:33:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yoav-ws.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pM82Tm8SYZvHBnWjrS6XZl1Nph3dGcYRs92TsOzZwdI=; b=R7rZVal0Zaz/c2zzFeFlvXI/hZfDywviqkQ/bcjlPqZOeEXWpFnbWILiWEsxCckQeB g+HXXvuLQqS8SmoDOaSMv2Lgh9vLZuqLPCAQExtp8DhPklHx6BIxa3eObRUT3t0/DZ9D QJwYuvWbngpyaIGioADA7BQH5UP1Ii3mBFfRht0SOGGrYEg7lTKVX9crU8WKFy3tV8xq hxJLyRcrchUZlcrpZU0Aj/85204nSBq27tJzuKnQLPeWmvnjk2BfHI80F1ffgu1sZ6/J y+usK70OygmJDbZhoCbvpViMMYo9TbB0JI0+TQqpogLeyMNPtp32XOEV15wN0KE/Tjkw ZBOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pM82Tm8SYZvHBnWjrS6XZl1Nph3dGcYRs92TsOzZwdI=; b=c79IGqXDakpTprUuCR6VpD2bCM4g8da4nH+pZ1Hvc6JtfIeo3R6DgwpCnX0tLDv3d8 jCgi0cA8ixFE8+ZTU6FOXdt99OpKpkieqL2z2w9JcI+AVigbRrYCYbw/2oF3/jSl71p1 QWMDc0mBXx/ZU5bGbRUfLP+RYNOsySBfX7zwC3yT7hMGS1fl2fxP+xbYbRCFX9TFHUf4 fmjujLNiLqiDM1G8HuF8Do5sthcvLWN3l3wPxcuNJ7KLMbilPU7AQ4KA+5ctEKTINuFp wpZ0Dg6ZRicfZ6KDd6NAQNlX7BuqbLDcl9mOPWgsCv+cP1if6npo+Z6zIZxWidJneT2+ XYWA==
X-Gm-Message-State: APt69E0nW6oXUbo+WPVLwMgjVU6+PQ11QJYqbDedxevan9Fpt1b7kqPY gQjOKknbtDUWFbotIPj9y+Z0IaKeVPhPvOjUFWU+9Q==
X-Google-Smtp-Source: ADUXVKLT9vKywHifR2kGonflyFMi9Rxpp1pRBnOR9WLLCZ6uyWanpd5Vk9HDYPHZq6N945D5DDChk91T0kaZUSXRqU4=
X-Received: by 2002:adf:ef4f:: with SMTP id c15-v6mr4057799wrp.182.1528450417147; Fri, 08 Jun 2018 02:33:37 -0700 (PDT)
MIME-Version: 1.0
References: <152524471147.10888.15768344253988846813@ietfa.amsl.com> <CANh-dXmhN3hVKLMiz_8Tr3M_-aZejcDAD+FcTXM7+1J-9=SzBQ@mail.gmail.com> <2DA552F8-076A-486E-8C52-26DEEA658731@mnot.net> <CADXXVKrFBeLJW=Mh70S1bzQct-X440Km_kkacefKE=PwpCsYhg@mail.gmail.com> <2F6C1117-648A-4DBA-BA2C-DB4A9356C7C8@mnot.net> <CACj=BEgtNcKs8LHAkK+Pnh0JeGZk0-0AmM8w4cziJVzXM25Ddw@mail.gmail.com> <847B7CC5-BB40-4C8B-BBB4-7C90FA93485C@mnot.net>
In-Reply-To: <847B7CC5-BB40-4C8B-BBB4-7C90FA93485C@mnot.net>
From: Yoav Weiss <yoav@yoav.ws>
Date: Fri, 08 Jun 2018 11:33:24 +0200
Message-ID: <CACj=BEj516WyXgPpqpEE_rRpq12noDyNwU-be8sr4zq+x9LkFw@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Ilya Grigorik <igrigorik@google.com>, Jeffrey Yasskin <jyasskin@google.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="0000000000002bd26b056e1e184f"
X-W3C-Hub-Spam-Status: No, score=-5.8
X-W3C-Hub-Spam-Report: AWL=3.902, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.795, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1fRDmW-0004Ao-4g 1d1d3e4a7c22ad9b28fd50a9284a23bc
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Variants and Client Hints
Archived-At: <https://www.w3.org/mid/CACj=BEj516WyXgPpqpEE_rRpq12noDyNwU-be8sr4zq+x9LkFw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/35517
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
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/ > >
- Re: Variants and Client Hints Mark Nottingham
- Re: Variants and Client Hints Ilya Grigorik
- Re: Variants and Client Hints Mark Nottingham
- Re: Variants and Client Hints Yoav Weiss
- Re: Variants and Client Hints Mark Nottingham
- Re: Variants and Client Hints Yoav Weiss
- I-D Action: draft-ietf-httpbis-variants-01.txt internet-drafts
- Variants and Client Hints Jeffrey Yasskin
- Re: Variants and Client Hints Mark Nottingham
- Re: Variants and Client Hints Leif Hedstrom
- Re: Variants and Client Hints Mark Nottingham
- Re: Variants and Client Hints Leif Hedstrom
- Re: Variants and Client Hints Leif Hedstrom
- Re: Variants and Client Hints Mark Nottingham
- Re: Variants and Client Hints Yoav Weiss
- Re: Variants and Client Hints Mark Nottingham