W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: Cache-control: max-age, uh, where?

From: Balint Nagy Endre <bne@bne.ind.eunet.hu>
Date: Thu, 14 Sep 1995 11:24:33 +0200 (MET DST)
To: Shel Kaphan <sjk@amazon.com>
Cc: http WG <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <42.bne@bne.ind.eunet.hu>
Shel Kaphan writes:
> The argument against it didn't take the request-header usage into
> account, because that doesn't overlap with other functionality in a
> non-orthogonal way.  My main problem with it is its redundancy with Expires,
> (as a response header) with which it appears to have almost identical
> semantics, though what happens if they are both present is not
> well defined.

If we have no difference between semantics for Cache-Control: max-age=<seconds>
and Expires: <date>, I propose one:

The basic semantics is common, both define a time limit until which
the request-URI can be served from a cache without contacting the
origin server.

If we have both expires and max-age,
before the expires date the request-URI can be served from cache,
after the expires date max-age takes over, until the expires date is
updated from the origin server.

When a conditional GET reports absolutely no change, (304 response code
and the same set of Last-Modified, Expires and Cache-Control: max-age
header field values):
the semantics is still undefined, if we have only Expires.
the request URI can be served from cache again for max-age seconds,
if we have only max-age.

Any hints for the still undefined case?

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>
Received on Thursday, 14 September 1995 02:32:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC