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

Re: Push and Caching

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 26 Aug 2014 11:37:33 -0700
Message-ID: <CABkgnnWssBqVw+aSb_8y80JBRWkQ8H+MPvmYZ7MyzOkYUQwWTQ@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
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'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".
Received on Tuesday, 26 August 2014 18:38:02 UTC

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