Re: Push and Caching

[Michael Sweet <[e-mail]>]

Push has always been talked about in the context of a server pushing data that the client would need to GET anyways, so why shouldn't we just use the same cache semantics for both a GET response and an pushed response?


On Aug 26, 2014, at 2:37 PM, Martin Thomson <[e-mail]> wrote:

> On 26 August 2014 09:59, Roy T. Fielding <[e-mail]> wrote:
>> "A recipient cache SHOULD consider a pushed response to be valid for the
>> duration of the connection (or until it is replaced during that connection)
>> even if the pushed response contains cache directives that would normally
>> indicate that the response is immediately stale."
> 
> Given the long-lived nature of HTTP/2 connections is this really the
> right bound on validity?  It's not as though the server is guaranteed
> an opportunity to replace/invalidate the response.
> 
> I'm a little leery of implying something about regular response
> validity in this context.  I couldn't find anything concrete in RFC
> 7234 about the period over which a response can be considered valid
> once it arrives at the client.  The best I could find was: "A cache
> need not validate a response that merely became stale in transit."
> 
> If anything 7234 uses validation in the instantaneous sense
> exclusively.  Freshness seems to be the only concept that is
> associated with a time period, but we're carefully avoiding that here.
> This, to my reading, is breaking new ground.  And people are right to
> notice the prefetch and request combining features as having
> interactions with this, even though those seem to be confined to web
> use cases.
> 
> I don't think that this is a defect of RFC 7234, but it's an issue
> that I'd prefer to see addressed more comprehensively than just for
> push.
> 
> ...and that's mainly why I suggested the "at the time that the
> response is generated".
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair