Re: [#153] PUSH_PROMISE headers

On 29 June 2013 07:27, James M Snell <jasnell@gmail.com> wrote:
> On Jun 29, 2013 1:03 AM, "Amos Jeffries" <squid3@treenet.co.nz> wrote:
>> The cache will store the pushed response under:
>>   hash(URL)+hash(Vary:"image/jpeg")
>>
>> When looking up future HIT the cache for this client on explicit-GET it
>> will look up
>>   hash(URL)+hash(Vary:"text/html, image/jpeg, image/gif")
>>
>> I assume you can spot the difference.
>
> I didn't miss that. Pushed resources and content negotiation used together
> have rather, um, "interesting" complications. However, those don't change
> the request headers in the push promise and response headers in the HEADERS
> question which is what I was addressing.

I think that we've reached a conclusion.  One very different to what
is described in SPDY/3 (the version we inherited).

A client without a cache entry will not care about what the cache key
was.  A client that has already received the document is likely to get
a cache miss due to the above effect, but at least the behavior is
"correct".  Subsequent pushes, assuming that the server is consistent
with itself, should produce a cache hit.

I can see a future for UA-sniffing here.  that makes me a little sad,
but optimizations tend to have that effect.

BTW, the idea of RST_STREAM+If-None-Match is appealing.  I've seen
lots of approaches to this problem and that is somewhat novel.  I
haven't thought it through fully, but it could add something,
depending in a number of conditions.  Like any optimization, it does
need to be tested out, and it's probably early days for that sort of
tweak.

Received on Monday, 1 July 2013 17:45:10 UTC