Re: Push and Caching

On Aug 26, 2014, at 11:37 AM, Martin Thomson wrote:

> On 26 August 2014 09:59, Roy T. Fielding <> 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 would expect them to push another.  Isn't that sufficient?

> 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."

Hmm, that effectively has the same meaning as what I proposed -- a
pushed response can be considered in-transit until it is used.

> 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".

But that has no value to the recipient.  Validation only occurs when
a response is used, and it is impossible to use a response at the time
it was generated.

I think we should just accept that a server is not going to push a
response if it expects a validation round-trip to be required for
its use.  Hence, let the server send another push if it wants to
invalidate what it already sent.


Received on Tuesday, 26 August 2014 19:05:25 UTC