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

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