RE: Push and Caching

[William Chow <[e-mail]>]

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

7234 refers to a response being valid in direct correspondence to a specific request. With HTTP2 and server push, there can be multiple responses that directly correspond to that "original request" (this is the term used in the HTTP2 draft). For server push to be effective, we really need this validity/freshness to expand to be 1-N relationship between the original request and all of the responses returned from the server for that request. We don't need to state how that is done (e.g. UAs/clients may implement a navigation context) but it doesn't help the recipient to understand the scope of validity for a pushed response if that validity is not relative to anything but itself.

> Pushed responses are considered successfully validated on the origin 
> server (...) at the time that the response is generated.

So, going back to the proposed language, it seems we can address this for HTTP2 because we have the notion of the "original request", such as: "Pushed responses are considered valid (...) at the time that the response for the original request is generated."

--Will