- From: James M Snell <jasnell@gmail.com>
- Date: Mon, 5 Aug 2013 14:48:14 -0700
- To: Robert Collins <robertc@squid-cache.org>
- Cc: Julian Reschke <julian.reschke@gmx.de>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Mon, Aug 5, 2013 at 2:34 PM, Robert Collins <robertc@squid-cache.org> wrote: >[snip] > Exactly! consider conditional gets: if the UA sends a GET I-M-S or a > GET I-N-M then the server can infer likely cached resources and PUSH a > HEAD->304for those resources the client probably has, and a GET->200 > for those that are definitely new. > Or the server simply chooses not to push the resources that haven't been modified. If the user-agent has them, it uses them, if it doesn't, it requests them again. Also, remember that the push is a server implied request.. that is, the server can assume that a GET request will be coming in so it crafts a set of request headers followed by the response. The following, then, would be identical to your suggestion: PUSH_PROMISE Promised Stream ID: 2 :method = GET :path = /images/f.jpg :if-modified-since: 2013-01-01T12:12:12Z HEADERS Stream ID: 2 :status = 304 last-modified: 2013-01-01T12:12:12Z This would still lead to the cache metadata being updated while holding to the suggested Implied GET rule. > So I think originating GET leading to PUSH of GET and HEAD makes a lot of sense. > > -Rob
Received on Monday, 5 August 2013 21:49:02 UTC