Re: Submitted new I-D: Cache Digests for HTTP/2
Stefan Eissing <stefan.eissing@greenbytes.de> Wed, 13 January 2016 09:44 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 91AD41ACD6A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 13 Jan 2016 01:44:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.003
X-Spam-Level:
X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 Yb5avm4XpIwO for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 13 Jan 2016 01:44:29 -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 176C11A6F8C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 13 Jan 2016 01:44:29 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aJHvL-0004zg-76 for ietf-http-wg-dist@listhub.w3.org; Wed, 13 Jan 2016 09:41:03 +0000
Resent-Date: Wed, 13 Jan 2016 09:41:03 +0000
Resent-Message-Id: <E1aJHvL-0004zg-76@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) 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 1aJHvJ-0004z2-Gk for ietf-http-wg@listhub.w3.org; Wed, 13 Jan 2016 09:41:01 +0000
Received: from mail.greenbytes.de ([217.91.35.233]) by lisa.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <stefan.eissing@greenbytes.de>) id 1aJHvC-0004IE-82 for ietf-http-wg@w3.org; Wed, 13 Jan 2016 09:41:00 +0000
Received: by mail.greenbytes.de (Postfix, from userid 117) id 691EC15A0730; Wed, 13 Jan 2016 10:40:32 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1452678032; bh=KE0lc7dX3plQYAMzjYfc9KA8iTw2M8h7e8F715TfV8w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=W+T4+iTUwWFqmIlI8B4bLU6IQzcbyEOeLyWvDtDv/SamEESuPbvt8ci6I73EIt/8R dnQXZUgeeqg/9cgxtUSu1Af9h8WuVwZKCdBTiEdaExhQOjbQ4V+9E20PdoecYnSRzO iF0SRDcOzIdd6DIMXXpxj+rV72UclkXMjFolesKk=
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 3BB5E15A0361; Wed, 13 Jan 2016 10:40:30 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1452678031; bh=KE0lc7dX3plQYAMzjYfc9KA8iTw2M8h7e8F715TfV8w=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=q02it5R2idl3sIx2Fm4i0w6RTsy1gMRw5dj8si+Jsr/xTq4zUfeZ6UDc4/D1Qji83 vBPEhUnDFkyFmjaN14hWFZ7JrHj7pieLk+tHvhIS+AMGyOCRt85oE0uBNbWrUGR0ga wzag18lcZ8HBg72iatuX3aYwp4/Wq4CoWZXN1Q68=
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: <CANatvzyOnMSLHfXcDrGSjbtZi5nFX2e9_4tHOjmR2OqBWEYUcg@mail.gmail.com>
Date: Wed, 13 Jan 2016 10:40:31 +0100
Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EDB7D8A6-9121-4268-8920-223E9BE16B19@greenbytes.de>
References: <CAAMqGzYUoCMxBxUEY9wfLOHZp7nrO4d1q5JZo=96pfEbVS1-ew@mail.gmail.com> <652C3E3A-3DA6-40BB-82FF-01A7D65FF65C@lukasa.co.uk> <CABCZv0piAoDnA1J+2pJ3HyF_iRwj9AaFGfonFjdKGfYr=cGZgQ@mail.gmail.com> <CAKRe7JG16u+MteBz4Rz7iCnHxfhLZ=QbWekrhgNhNkq+pKhVAg@mail.gmail.com> <CANatvzyT_ohm5hEcJ1o8B+AEa70607E-LUnPp5cD8sSO8X0HKA@mail.gmail.com> <56958980.1030307@treenet.co.nz> <CANatvzyOnMSLHfXcDrGSjbtZi5nFX2e9_4tHOjmR2OqBWEYUcg@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.1
X-W3C-Hub-Spam-Report: AWL=-1.058, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1aJHvC-0004IE-82 ae485b49aa4a637094da9d767dde706f
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/EDB7D8A6-9121-4268-8920-223E9BE16B19@greenbytes.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30916
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>
> Am 13.01.2016 um 06:04 schrieb Kazuho Oku <kazuhooku@gmail.com>: > > 2016-01-13 8:17 GMT+09:00 Amos Jeffries <squid3@treenet.co.nz>: >> On 12/01/2016 2:20 p.m., Kazuho Oku wrote: >>> 2016-01-12 0:39 GMT+09:00 Ilya Grigorik: >>>> Glad to see this proposal! >>>> >>>> FWIW, another +1 for enabling this functionality via an HTTP header. >>>> Limiting it to h2 frames makes it effectively inaccessible to web developers >>>> that want to experiment with own cache management logic (via ServiceWorker, >>>> etc). >>> >>> Glad to hear from you. >>> >>> While it is possible to use an HTTP header to implement cache-digest >>> (and that is what we are doing now in H2O + ServiceWorker/cookie), I >>> believe it should ideally be implemented as an HTTP/2 header since: >>> >>> * including the digest value (the value changes as client receives >>> responses) in every HTTP request is a waste of bandwidth >> >> Bandwidth may or may not be a problem relative to the digest design and >> amount of compression applied by the protocol (eg. h2 dynamic table vs >> HTTP/1.1 repetition). > > That is generally true. > > However the specification will become complicated if we are to include > the cache digest in the headers, while achieving a good compression > ratio. > [...] > To summarize, the draft utilizes the fact that HTTP/2 multiplexes HTTP > requests into a single, ordered stream to make things simple. > Considering the fact that we need to rely on HTTP/2 to push things > anyways (that is the primary target of the draft), I think that is a > reasonable trade-off. There might be use cases to a) transport a cache digest over HTTP/1.1 b) expose a cache digest to a web application I think the draft could define a header field for this purpose and describe its use. Specifically - HTTP/1.1 clients should make it a Connection header - HTTP/1.1 to H2 transformers may use it in calculating their CACHE_DIGEST frames (depending on their caching strategy) - similar for H2 to HTTP/1.1 gateways So this header, let's call it "Cache-Digest" for the sake of discussion, could appear in HTTP/1.1 requests or on web server and clients internal APIs: ... Cache-Digest: <base64url encoded, golombset compressed digests> Connection: Cache-Digest ... The question is what a H2 origin server does with such a header, should it appear. Ignore, discard? I don't see that the draft should care about H2 header compression efficiency of such a beast. Sending it over H2 seems more a curiosity to me. -Stefan > >>> * cache state is an information that is bound to the connection, not >>> to a request >> >> You assume a browser endpoint cache. >> >> Intermediary caches are constructed from content flowing over multiple >> parallel connections. Potentially from multiple origins. Which makes it >> very likely to have changed between any two given requests to contain >> things that cannot be inferred by the server from those two requests. > > Do you consider that caching proxies should establish multiple > connections to upstream when using HTTP/2? > >> This type of problem is also more likely to happen in the presence of >> domain sharding. Where the temporal locality of the index request is >> different from the 100's of content requests. >> >> ALTSVC may also make similar things happen with browser caches. >> >> Amos >> > > > > -- > 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