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

[Kazuho Oku <[e-mail]>]

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