W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Push and Caching

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 26 Aug 2014 12:05:03 -0700
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <DE38D1FB-C9E1-441F-BDCE-9258714E0D96@gbiv.com>
To: Martin Thomson <martin.thomson@gmail.com>
On Aug 26, 2014, at 11:37 AM, Martin Thomson wrote:

> On 26 August 2014 09:59, Roy T. Fielding <fielding@gbiv.com> 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.

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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC