- From: Kazuho Oku <kazuhooku@gmail.com>
- Date: Tue, 12 Apr 2016 15:11:25 +0900
- To: Alcides Viamontes E <alcidesv@zunzun.se>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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
Received on Tuesday, 12 April 2016 06:11:54 UTC