Re: Submitted new I-D: Cache Digests for HTTP/2

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, Attribution­ShareAlike). 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
>