- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 26 Aug 2014 11:37:33 -0700
- 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