Re: Submitted new I-D: Cache Digests for HTTP/2
Stefan Eissing <stefan.eissing@greenbytes.de> Thu, 21 January 2016 11:13 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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD451A711A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 21 Jan 2016 03:13:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.793
X-Spam-Level:
X-Spam-Status: No, score=-6.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham
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 g7tIvrD2yXCv for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 21 Jan 2016 03:12:57 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B454B1A70E2 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 21 Jan 2016 03:12:57 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aMD75-0004rJ-3i for ietf-http-wg-dist@listhub.w3.org; Thu, 21 Jan 2016 11:09:15 +0000
Resent-Date: Thu, 21 Jan 2016 11:09:15 +0000
Resent-Message-Id: <E1aMD75-0004rJ-3i@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <stefan.eissing@greenbytes.de>) id 1aMD73-0004qE-Cy for ietf-http-wg@listhub.w3.org; Thu, 21 Jan 2016 11:09:13 +0000
Received: from mail.greenbytes.de ([217.91.35.233]) by maggie.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <stefan.eissing@greenbytes.de>) id 1aMD70-0005MV-Sa for ietf-http-wg@w3.org; Thu, 21 Jan 2016 11:09:12 +0000
Received: by mail.greenbytes.de (Postfix, from userid 117) id 8DD6A15A0F63; Thu, 21 Jan 2016 12:08:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1453374527; bh=88Gbe7ydhdJuxUJfxLGkW2ZGlz/1G1it3R4/hNeajsI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=WfEo6AtR1ZvvwIYbKwGkeZc7h6nUI9s/4o4KXdkbzy49+8pMcQB83wh8ehoPHpH5Z AnfShOJ3bBhfkRfV6RhXBSvyC8U9hMaj6n0tLbXmhxiErJDAWQoVC95VOIdQ39LIbJ y7FPyCx9stKTxySij2MLa6w3BzWZNPQ23ZOk3zEw=
Received: from [192.168.1.42] (unknown [217.91.35.233]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 8B78915A068F; Thu, 21 Jan 2016 12:08:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1453374526; bh=88Gbe7ydhdJuxUJfxLGkW2ZGlz/1G1it3R4/hNeajsI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=ftdQAjqTDwH3bVjBOIzEX1l/1W+Q5z0fV9DP1cWOcc7147YLFeby3uOQH+hRQr5GL TildiycpHisJfxmk7ZBRkroq98RpGA7fSXU3N8yTh2490t/4+hwl/Qwd613NtLyxIN F4rKCtgOTLFJWiUWFAd6my6FI/YTP6Cl04TTThlc=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Stefan Eissing <stefan.eissing@greenbytes.de>
In-Reply-To: <CANatvzxrYpMpzSTi8KdoGjF0mQHcuvFDmpVPozXX40MgXBR-kw@mail.gmail.com>
Date: Thu, 21 Jan 2016 12:08:45 +0100
Cc: Julian Reschke <julian.reschke@gmx.de>, Martin Thomson <martin.thomson@gmail.com>, Ilya Grigorik <ilya@igvita.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FD8C9E08-DBD3-418B-AF3C-7762D72B2207@greenbytes.de>
References: <CAAMqGzYUoCMxBxUEY9wfLOHZp7nrO4d1q5JZo=96pfEbVS1-ew@mail.gmail.com> <CANatvzw6NpbpA_56GbSiCH2yEQoAuaGtXneOvrogBfucqrC8Qw@mail.gmail.com> <CAKRe7JGUUAinAqM9yHnUp0gJm5qwq5xvMhEo+fMnffRW7Kmu7w@mail.gmail.com> <CANatvzxhCXKRFEVJDeJfdMVxP6r+jyOSCcHkY8VHiPNCSF+SwA@mail.gmail.com> <CABkgnnVdR0fi9QKHT=tZUzAzAYe+XxG-oEj=srZGX0TMEkHcuw@mail.gmail.com> <CANatvzwPmZXEpcjE+O2BORq19FgGNGYgs7D7t-t_1O0-x-75KA@mail.gmail.com> <CABkgnnUrbBzKRZZsRzAf93A1Gj3AZQAfNpnBQLRqXzQFnRNwwA@mail.gmail.com> <CABkgnnWkNynANyjGUkcZBTQjUsVDvDZYA+-zr9BD3+BK3xLNmQ@mail.gmail.com> <CANatvzxMGnodspx1sfCVOOjuLKBFM-ySFM-1A3yrw7nyMLyugw@mail.gmail.com> <CABkgnnUGBj5NZWhqEaSLe5Bj_htyJsk5pX=YAWeFj+prHZUhAA@mail.gmail.com> <CANatvzxOqFgrvExSRzYJKHboQT6kKdUg6XpaUCQC3yY2dnsJtg@mail.gmail.com> <CABkgnnXh3yd2C5F8Q22JePFtwb7P6mXUQGVzFRdVipJGDdA6cg@mail.gmail.com> <6D423053-CB64-408A-A119-3B4174221287@greenbytes.de> <569CBF3E.30509@gmx.de> <CANatvzw2JPmii3x9Wm4qH2v4XmDXLxjizmpDc7yodG12yR7_hw@mail.gmail.com> <9EEFEA0A-BA B7-4594-8F6B-62B0B9459D41@greenbytes.de> <CANatvzxrYpMpzSTi8KdoGjF0mQHcuvFDmpVPozXX40MgXBR-kw@mail.gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
X-Mailer: Apple Mail (2.3112)
Received-SPF: pass client-ip=217.91.35.233; envelope-from=stefan.eissing@greenbytes.de; helo=mail.greenbytes.de
X-W3C-Hub-Spam-Status: No, score=-5.4
X-W3C-Hub-Spam-Report: AWL=-1.651, BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1aMD70-0005MV-Sa ba6afe256fc855b739a480c64b20e7b0
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Submitted new I-D: Cache Digests for HTTP/2
Archived-At: <http://www.w3.org/mid/FD8C9E08-DBD3-418B-AF3C-7762D72B2207@greenbytes.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30994
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: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Kazuho, thanks for your detailed feedback. I see that you have things in mind for cache digest that I had not understood. I would still argue for the standalone digest form and define a new parameter that specifies the digest type. For example: Cache-Digest: base64urldigest;type=fresh, base64digest;type=if-modified-since with a default of "fresh". To your other points, I agree. > Am 21.01.2016 um 02:26 schrieb Kazuho Oku <kazuhooku@gmail.com>: > > 2016-01-20 21:57 GMT+09:00 Stefan Eissing <stefan.eissing@greenbytes.de>: >> I make another attempt, based on the feedback (Kazuho, please stop me if you prefer to work on this): > > Sorry. I thought I had responded to your email. It has always been > my pleasure (and fun) to discuss how we should design and implement > cache digests. > > I think we mostly agree on how the header should be designed. > > Below, I will cover the semantic differences between yours and mine > (laid out in https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0120.html), > and my thoughts. > >> Cache-Digest = "Cache-Digest" ":" #digest-value >> >> digest-value = base64url-encoded-digest *( ";" digest-param ) > > I would like to have the encoded digest stored as a name-value pair, > thereby allowing the client to store several types of digests within a > single digest-value. > > At the moment, the draft only covers how the digests of fresh > resources in cache should be encoded. However if all goes well, I > anticipate that we would extend the spec., to support stale resources > as well. For such purpose, being able to store more than one type of > digests in a single digest-value would make the header less redundant. > > As an example, the header conveying a digest for fresh resources and a > digest for stale resources with if-modified-since headers can look > like: > > cache-digest: fresh=xxxxx; if-modified-since=yyyyy; authority=*.example.com > > only in case if we use name-value pairs to encode the digest. > >> A digest replaces any existing digest if its domain parameter >> matches the domain of an existing digest (with '*' matching any >> domain) and the path parameter is a prefix of or equal to the >> existing path. > > I believe that a server should be able to determine the domain(s) the > client considers the server to be authoritative for. > > Therefore, I think that a) the default scope should be the value > passed in by the `:authority` pseudo header, and b) otherwise the > client should explicitly specify the scope using the language defined > in RFC 6125 6.4.3. > > Unless the scope is transferred over HTTP, HTTP servers need to have > the knowledge of the common name in the TLS certificate being used. > However that might not always be easy considering the fact that in > some cases TLS terminators (run by a different entity) might be placed > in front of the HTTP server, or in case we want to rolling-update > certificates of a TLS terminator cluster from a host-level certificate > to a wildcard certificate. > > Requiring the client to always specify the scope of the digest aligns > with the fact that in HTTP/1.1 and HTTP/2 specifications the Host > header (or the :authority header) is transferred even if TLS > certificate is used (and the fact that not the common name stored in > the certificate but the value of the header IS used as the name of the > authority). > >> If the codec of a digest is unknown, the digest MUST be assumed >> to be empty > > If the codec of a digest is unknown, a server must behave as if it did > not receive that digest. > > Assuming it to be empty would mean that a server will consider the > cache of the client to be empty. It should mean to the server that > the client's cache state is unknown (for the category of the resources > (e.g. fresh)). > > And this definition is important for extending the spec., to cover > stale resources. For example, if a client sends a digest of fresh > resources and a digest of stale resources, a server knowing only how > to handle the former should respect the former and ignore the latter. > >> A candidate of a server push is matched against a cache digest >> by comparing its :authority against the digest domain (port number?) >> and its :path against the digest path (equal or prefix). Only >> then is the candidate matched against the digest content. > > Agreed. > >> >>> Am 18.01.2016 um 15:46 schrieb Kazuho Oku <kazuhooku@gmail.com>: >>> >>> 2016-01-18 19:32 GMT+09:00 Julian Reschke <julian.reschke@gmx.de>: >>>> On 2016-01-18 11:19, Stefan Eissing wrote: >>>>> >>>>> +1 generic header parameter form. >>>>> >>>>> If I may make a proposal: >>>>> >>>>> Cache-Digest = "Cache-Digest" ":" #digest-value >>>>> digest-value = "<" base64url encoded digest ">" *( ";" digest-param >>>>> ) >>>>> digest-param = ( ( "domain" "=" domain-value ) >>>>> | ( "path" "=" path-value ) >>>>> | ( "codec" "=" codec-value ) >>>>> | ( "update" ( "=" update-param ) ) >>>>> | ( digest-extension ) ) >>>>> >>>>> digest-extension = ( parmname [ "=" ( ptoken | quoted-string ) ] ) >>>>> >>>>> domain-value = >>>>> authority # defined in RFC3986 >>>>> | wildcard-identifier # defined in RFC 6125 6.4.3 >>>>> >>>>> path-value = path-absolute # defined in RFC3986 3.3 >>>>> >>>>> codec = ( "GCS-SHA256" | ( ptoken | quoted-string ) ) >>>>> ... >>>> >>>> >>>> I wouldn't use angle brackets here; let's leave them for use in places where >>>> the value is a URI (Link header field and several WebDAV header fields). >>>> >>>> Just us token/quoted-sting here. >>>> >>>> Also, do not wire parameter names into the ABNF; this mixes syntax with >>>> semantics. >>> >>> Thank you for the advice. >>> >>> Obviously I have used an old-fashioned RFC as a reference when writing >>> the ABNF (that Stefan probably modified). I should have looked into a >>> newer one, such as the Alt-Svc draft. >>> >>>> Best regards, Julian >>> >>> >>> >>> -- >>> Kazuho Oku >>> >> > > > > -- > Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alex Rousskov
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alex Rousskov
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alex Rousskov
- Re: Submitted new I-D: Cache Digests for HTTP/2 Cory Benfield
- Re: Submitted new I-D: Cache Digests for HTTP/2 Chris Bentzel
- Re: Submitted new I-D: Cache Digests for HTTP/2 Ilya Grigorik
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Amos Jeffries
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Amos Jeffries
- Re: Submitted new I-D: Cache Digests for HTTP/2 Ilya Grigorik
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Cory Benfield
- Re: Submitted new I-D: Cache Digests for HTTP/2 Ilya Grigorik
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Julian Reschke
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Richard Bradbury
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Eliezer Croitoru
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Eliezer Croitoru
- Re: Submitted new I-D: Cache Digests for HTTP/2 Richard Bradbury
- Re: Submitted new I-D: Cache Digests for HTTP/2 Amos Jeffries
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- RE: Submitted new I-D: Cache Digests for HTTP/2 Mike Bishop
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Stefan Eissing
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Martin Thomson
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- RE: Submitted new I-D: Cache Digests for HTTP/2 Mike Bishop
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E
- RE: Submitted new I-D: Cache Digests for HTTP/2 Mike Bishop
- Re: Submitted new I-D: Cache Digests for HTTP/2 Patrick McManus
- Re: Submitted new I-D: Cache Digests for HTTP/2 Kazuho Oku
- Re: Submitted new I-D: Cache Digests for HTTP/2 Alcides Viamontes E