- From: Koen Holtman <koen@win.tue.nl>
- Date: Wed, 6 Sep 1995 22:03:44 +0200 (MET DST)
- To: John Franks <john@math.nwu.edu>
- Cc: sjk@amazon.com, mogul@pa.dec.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
John Franks:
[..conditional GETs on Expires: yesterday documents..]
>This usage encodes some very non-intuitive semantics in the Expires:
>heading.
I don't think this is the case. Expires: yesterday does not express
that the client is permitted to `conditionally cache'(*) a reply,
because clients are _always_ allowed to do that, except when
explicitly disallowed by Cache-control: no-cache or Cache-control:
private.
(*) conditional caching: to keep a (possibly stale) response in proxy
memory for the benefit of future conditional GETs.
> If you want to tell the proxy to cache a document but always
>validate it then create a header or Pragma to do that.
The header is already there: Cache-control: max-age=0 in HTTP/1.1.
[...]
> Trying to
>encode this request in an otherwise meaningless variant of an existing
>header is a mistake.
As argued above, Expires does not _request_ conditional caching at
all. It only disallows unconditional caching.
> This will inevitably lead to confusion because
>most people already think they know what Expires: means and they
>have a right to think that.
^^^^^^^^^^^^^^
Sure they have a right to think that, but they do not have the right
to be called spec-compliant if they try to reverse-engineer the spec
from the names of the headers and fail.
If you keep in mind that Expires applies to the copy of the resource
in the response, not to the `master copy' at the origin server,
Expires is not such a bad header name at all.
>John Franks
Koen.
Received on Wednesday, 6 September 1995 13:07:23 UTC