- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Fri, 21 Mar 2014 18:50:39 +1300
- To: ietf-http-wg@w3.org
On 21/03/2014 12:59 p.m., Mark Nottingham wrote: > That's interesting. Probably just a Cache-Control directive, e.g., > > Cache-Control: max-age=60, once > > Like you say, just a hint. > I dont get why there is a need to involve new protocol extensions at all for this use case. A server which wishes the client to get it immediately and avoid caching is already free to send Cache-Control:no-store or max-age=0 to prevent intermediaries caching it regardless of what happend to the PUSH. A Server which wishes the client to be able to pull it from cache once can use Cache-Control:private,must-revalidate so no other client gets it and a no-store and/or Expires can be attached on the revalidation reply to purge it from cache. Intermediaries which support per-client caching can make use of the private to store it and respond to a delayed GET as a revalidated private object. If an intermediary is not going to relay the PUSH on to the client and not to cache it per-client at all then there is no way for the use-case to work regardless of protocol specs. So where does the new protocol semantics or extensions come in? It may not work today due to use-cases not being implemented for yet but that is not a protocol issue AFAICT. Amos
Received on Friday, 21 March 2014 05:51:07 UTC