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

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

Received on Wednesday, 10 February 2016 07:27:21 UTC