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

[Alcides Viamontes E <[e-mail]>]

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.
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.


On Fri, Apr 8, 2016 at 3:44 PM, Kazuho Oku <[e-mail]> wrote:

> 2016-04-08 3:55 GMT+09:00 Alcides Viamontes E <[e-mail]>:
> >
> > 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 <[e-mail]> wrote:
> >>
> >> 2016-02-10 16:02 GMT+09:00 Stefan Eissing <[e-mail]
> >:
> >> > 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 <[e-mail]>:
> >> >>
> >> >> Hi,
> >> >>
> >> >> 2016-02-09 20:46 GMT+09:00 Alcides Viamontes E <[e-mail]>:
> >> >>>>> 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
>