Re: Submitted new I-D: Cache Digests for HTTP/2
Alcides Viamontes E <alcidesv@zunzun.se> Tue, 12 April 2016 20:54 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 C374612DCFC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 12 Apr 2016 13:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.916
X-Spam-Level:
X-Spam-Status: No, score=-7.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zunzun-se.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 fSplsqX6NOMW for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 12 Apr 2016 13:54:20 -0700 (PDT)
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 9B00F12DEF3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 12 Apr 2016 13:54:20 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aq5Fd-0003s6-K0 for ietf-http-wg-dist@listhub.w3.org; Tue, 12 Apr 2016 20:49:33 +0000
Resent-Date: Tue, 12 Apr 2016 20:49:33 +0000
Resent-Message-Id: <E1aq5Fd-0003s6-K0@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 <alcidesv@zunzun.se>) id 1aq5FY-0003r2-00 for ietf-http-wg@listhub.w3.org; Tue, 12 Apr 2016 20:49:28 +0000
Received: from mail-vk0-f52.google.com ([209.85.213.52]) by maggie.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <alcidesv@zunzun.se>) id 1aq5FV-0005tC-FE for ietf-http-wg@w3.org; Tue, 12 Apr 2016 20:49:27 +0000
Received: by mail-vk0-f52.google.com with SMTP id e185so42052583vkb.1 for <ietf-http-wg@w3.org>; Tue, 12 Apr 2016 13:49:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zunzun-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=n8wC3OH28k5fqEHT5rQjI9AfzkLUn/zTqYWMbV8kPeg=; b=YI1wlG7+vKCH9vQ/9NC1SkHGFLlaDmf9GqlSXP087D23GVAsp0v53+vv9094rOAY2n xaKV2fPmKcaW6zL+ukqD6TlMkATiRs/Tb0YjOsvY7dkXiKzDTxCxAh3XtERsbxzsp6cn BWVQvP8T0fB3JNN2bVI11Ww0A6/us3IFnf6YEHyykKAaVtBX2lzDpMNKLSH7x5j9nTo0 tZXUBIk5v6XTCek5aog0Z0qYeuTXCGSXVEQaSu5I7R5BtCr2oyCL5rf9V8JKWikPEFjU lAG5BB3wAUONLzkPeqmbXGpOeiGTttXPyFPD53m+4j9UMBc+sIg2I9y6prObn8HTy7DR Q2Mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=n8wC3OH28k5fqEHT5rQjI9AfzkLUn/zTqYWMbV8kPeg=; b=Z3OI/mSCgYHdND4gqP1RKqYtKJ4E271NXof7vIHM5gYDOMQs31WIJ+GLx8khkB8c3f +zHalwCLX7B1/NvYdlGTeZLDggOvhgVvl3uP+370MCqCJQnao/d/a/Mo8PZDIFCfFDI6 1mBUO/eT47gHQZIwMtegHUKZxvAIkrc1QgEnxcEwgUomha5lWNbrc1ecEBVmB9+zSqjq 9wDivWdJ+FZCxCsUYsUTXFAqzb4ghqqiQq+oQ4hREvC4VbMBItVycXw3vRcHi76HH8Z6 MfcgUzKzDy8cwzHvFft3DCocQ1xgTccFjbwUEm24mOdk9/qT1Nndo3Yn0TSh2ONxZQgU 4U5A==
X-Gm-Message-State: AOPr4FVK83H0dv9uQEAy0tcOxllqhVJnyWTZQ3FBjRfF9mhSfy68t59m0EfDq1nRUkPlL+893MzdVXochtb0CQ==
MIME-Version: 1.0
X-Received: by 10.31.5.71 with SMTP id 68mr2709840vkf.25.1460494137976; Tue, 12 Apr 2016 13:48:57 -0700 (PDT)
Received: by 10.31.89.66 with HTTP; Tue, 12 Apr 2016 13:48:57 -0700 (PDT)
In-Reply-To: <CANatvzxDnumnfuSuWEqQFqskFk1nT6PXP_mRL6NsXYnJkGxy=A@mail.gmail.com>
References: <CANatvzxcKS46iAqAdfBHuWPt5k3XkR79NDMPPtDakOb2jPAywA@mail.gmail.com> <56A26B1E.4050303@rd.bbc.co.uk> <CANatvzyHbyrK7cjh+JsRpTR42knc6LXX7GWzj8ZEYPgv8cs49g@mail.gmail.com> <56B0F0DC.3060807@rd.bbc.co.uk> <56B110EE.5050705@treenet.co.nz> <CABkgnnU=BEPC=2X1f+DKDd11CrEG1awDG=j+J-Ha3B-mTPxfvA@mail.gmail.com> <CY1PR03MB137425A025736905630C91BF87D00@CY1PR03MB1374.namprd03.prod.outlook.com> <CAAMqGzbuSNYC6ResLR=NT5bLoDFDBn+=jjk00jKTN2v5TFSZ5Q@mail.gmail.com> <CANatvzzUQ+TEFZ5kML+Eagsb_O2pdmWosjMx_xspzrsCTy2hkA@mail.gmail.com> <F6EC743C-187F-4189-B78B-51079FBB5F02@greenbytes.de> <CANatvzzYKy0L3h+_-cEZXR7W+NbGhMg7BchsaZd0uVuQSpig-g@mail.gmail.com> <CAAMqGzZZCrjLmZhR3XmsF+1C1NbwdgVQ8w-p1QBNejoFpOWDuA@mail.gmail.com> <CANatvzxTO3fRj_+4W+PEURfOt_h7ZPB2RDc0Kn7_tWUrepQfDg@mail.gmail.com> <CAAMqGzbZjOocXkbE8aC7qObiL2izMvwy_qa8GdaTsVXwywkzQQ@mail.gmail.com> <CANatvzxDnumnfuSuWEqQFqskFk1nT6PXP_mRL6NsXYnJkGxy=A@mail.gmail.com>
Date: Tue, 12 Apr 2016 22:48:57 +0200
Message-ID: <CAAMqGzbNGU2D+mgBX9wAVADJ-3-G20t5A7Pb1iT8BUZfsPJVPw@mail.gmail.com>
From: Alcides Viamontes E <alcidesv@zunzun.se>
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="001a1143d2e04a810d05304fcacd"
Received-SPF: pass client-ip=209.85.213.52; envelope-from=alcidesv@zunzun.se; helo=mail-vk0-f52.google.com
X-W3C-Hub-Spam-Status: No, score=-5.4
X-W3C-Hub-Spam-Report: AWL=-0.818, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1aq5FV-0005tC-FE 11e06d8c51702a3461dfb670bd0c5b58
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/CAAMqGzbNGU2D+mgBX9wAVADJ-3-G20t5A7Pb1iT8BUZfsPJVPw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31429
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>
Thanks for the Github link Kazuho! It's a start. On Tue, Apr 12, 2016 at 8:11 AM, Kazuho Oku <kazuhooku@gmail.com> wrote: > 2016-04-10 17:14 GMT+09:00 Alcides Viamontes E <alcidesv@zunzun.se>: > > Thanks Kazuho, > > > > Regarding your question of how many fresh resources being cached, that > will > > change from site to site > > but we already have some statistical data that we can use to model some > > rough estimations. > > We will add that to our report. > > Great! I am eager to see that. > > > Also we will try to experiment a bit with a polyfill implementation (can > you > > point to any already existent one?) > > exposed to a little bit of normal traffic, > > and see where that get us. > > AFAIK there is no client that exactly implements the cache digest > frame (as defined in the draft). > IIRC https://github.com/Jxck/dispenser.js is a work-in-progress SW > code that implements the H2O's variant of the cache digest that uses > Cookies. > > > > > > > On Fri, Apr 8, 2016 at 3:44 PM, Kazuho Oku <kazuhooku@gmail.com> wrote: > >> > >> 2016-04-08 3:55 GMT+09:00 Alcides Viamontes E <alcidesv@zunzun.se>: > >> > > >> > Hi everybody, > >> > > >> > Our company got a little bit of money from the the Swedish government > >> > to do > >> > some research on the general idea of cache digests and on anything > that > >> > helps this digests proposal evolve forward. > >> > >> Wow! Fantastic! > >> > >> > As you may suspect, the results > >> > will be public (source code under BSD 3 and technical report under > >> > Creative > >> > Commons, AttributionShareAlike). So, regarding the current status of > >> > this > >> > proposal, what would you consider the most urgent issue that needs to > be > >> > addressed/researched-further/solved ? > >> > >> I think what we need most is a research on how large a cache digest > would > >> be. > >> > >> If the size of an average digest is say, for example 100 octets, I > >> think many of us would be happy on adopting the draft. On the other > >> hand if the result is 10,000 octets, I think we need to update the > >> draft so that a more fine-grained digest (e.g. a digest that only > >> contains resources that block the rendering path) can be created. > >> > >> So the question boils down to two. > >> > >> Q1. How many fresh resources exist per origin? > >> > >> The size of the cache-digest is proportional to the number of fresh > >> resources being cached, and it would be of great help if we could find > >> out the number. > >> > >> Q2. What is the appropriate value for P? > >> > >> The size of the cache-digest is proportional to log2(P), so we would > >> like to select a small but effective value. > >> > >> If, in average, a client needs to fetch 10 additional resources per > >> every pull request, a cache digest using P=2 might be still useful, > >> since in average 5 resources can be pushed. > >> On the other hand if in many cases a client needs to fetch 1 or 2 > >> additional resources per every pull request, we would need to have a > >> greater default for P. > >> > >> > >> Of course there would be other things to look at, but IMO these two > >> questions are the ones many would be interested to know. > >> > >> > In advance, kind thanks for your time. > >> > > >> > Alcides Viamontes E. PhD > >> > Zunzun AB. > >> > > >> > > >> > > >> > > >> > On Wed, Feb 10, 2016 at 8:26 AM, Kazuho Oku <kazuhooku@gmail.com> > wrote: > >> >> > >> >> 2016-02-10 16:02 GMT+09:00 Stefan Eissing > >> >> <stefan.eissing@greenbytes.de>: > >> >> > Is PUSHing a HEAD request, unconditional, not what you are looking > >> >> > for? > >> >> > >> >> Thank you for the suggestion. I hadn't thought about using HEAD, but > >> >> it sounds like an elegant solution. > >> >> > >> >> Pushing HEAD requests with validators stored in the responses would > be > >> >> much easier and straightforward to define and / or implement than > >> >> trying to determine how to push conditional requests. > >> >> > >> >> Do the web browsers recognize pushed HEAD requests? > >> >> > >> >> >> Am 10.02.2016 um 02:50 schrieb Kazuho Oku <kazuhooku@gmail.com>: > >> >> >> > >> >> >> Hi, > >> >> >> > >> >> >> 2016-02-09 20:46 GMT+09:00 Alcides Viamontes E < > alcidesv@zunzun.se>: > >> >> >>>>> Not something that we've implemented yet, but it's a valid > >> >> >>>>> scenario. > >> >> >>> > >> >> >>> Pushing 304 works both in Chrome and Firefox: > >> >> >>> https://drive.google.com/open?id=0B2F2m0rSqGCVWFJnTzRWOWFWQmc , > we > >> >> >>> have been > >> >> >>> doing it for some time. > >> >> >> > >> >> >> My understanding is that handling of pushed 304 in Chrome and > >> >> >> Firefox > >> >> >> is unreliable. > >> >> >> > >> >> >> When sending a push, a server cannot be 100% certain if the client > >> >> >> has > >> >> >> the resource cached. In other words, there is always a > possibility > >> >> >> that the pushed response will be considered as a response to a > >> >> >> non-conditional HTTP request on the client side. > >> >> >> > >> >> >> In other words, browsers that support 304 push should, when > matching > >> >> >> a > >> >> >> pushed 304 response against a HTTP request, check that the request > >> >> >> is > >> >> >> conditional, and use the pushed response only if the request was > >> >> >> conditional (additional checks might be necessary). Otherwise, > the > >> >> >> pushed 304 request must be ignored, and the browser should pull > the > >> >> >> unconditional HTTP request. > >> >> >> > >> >> >> However, my understanding is that both Chrome (48.0.2564.103) and > >> >> >> Firefox (44.0.1) don't do the check; they consider pushed 304 > >> >> >> responses to be a response to a unconditional HTTP request. > >> >> >> Therefore, there is a chance that you would fail to deliver the > >> >> >> correct content if you use 304 push today. > >> >> >> > >> >> >> -- > >> >> >> Kazuho Oku > >> >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> Kazuho Oku > >> > > >> > > >> > >> > >> > >> -- > >> 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