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

[Kazuho Oku <[e-mail]>]

2016-04-10 17:14 GMT+09:00 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.

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



-- 
Kazuho Oku