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

RE: Push and Caching

From: William Chow <wchow@mobolize.com>
Date: Tue, 26 Aug 2014 23:07:14 +0000
To: Martin Thomson <martin.thomson@gmail.com>
CC: "Roy T. Fielding" <fielding@gbiv.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <ee6c28ad51ab4022a6346ffb836bf770@DM2PR05MB670.namprd05.prod.outlook.com>
>> 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).
>That's not right.  Server push always provides a request.  The only difference is that it is synthesized by the server.

I am referring to this paragraph in 8.2:

"HTTP/2 allows a server to pre-emptively send (or "push") responses (along with corresponding "promised" requests) to a client in association with a previous client-initiated request. This can be useful when the server knows the client will need to have those responses available in order to fully process the response to the original request."

Note that I didn't say the server *didn't* also push the request. I am only referring to the notion stated above that those pushed responses are "in association with a previous client-initiated request". Perhaps you disagree with my use of the term "correspond", so "in association" is fine by me. 

Upon further reflection, the time of the generation of a pushed response is going to be effectively the same time as the generation of the response to the original request, so perhaps there isn't much practical difference between your proposed text and mine. What I am hoping we'd be able to do is to include language that describes the relationship between the original request/response and the pushed responses, so that caches have guidance on when it is safe to serve a pushed response when the client-initiated request is actually received later from the UA. 

For your proposed text that says a pushed response is validated at the time it was generated, this seems so obvious as to not have any value for the no-cache case. Specifically, it seems that a pushed no-cache response should only be valid when *used* in combination with the response it was pushed with. I think this is what Roy F. was alluding to in his other response (about not preventing use, but to discourage reuse). While we can call out the no-cache case specifically, it seems we don't really need to if we had language that coupled the pushed responses's validity with their associated original request/response.


Received on Tuesday, 26 August 2014 23:07:46 UTC

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