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

Re: Server push limited to cache priming?

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Fri, 21 Mar 2014 18:50:39 +1300
Message-ID: <532BD32F.3000202@treenet.co.nz>
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.

Received on Friday, 21 March 2014 05:51:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:25 UTC