- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Wed, 17 Apr 96 15:21:28 MDT
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
One comment on this:
* Cache-control: Max-Age=0 or Expires:<a date in the past>.
(Example: Expires: Thu, 01 Jan 1980 00:00:00 GMT), to ``pre-
expire'' a cache entry. The resource may be cached, but the cache
must validate it before returning it to the client.
The word "must" here is not accurate if "max-age=0" is used. The
protocol explicitly allows caches to "cheat" on expiration dates,
not because I think it's a good idea, but because people have insisted
that they will do it anyway.
Although there is some residual grumbling about it, the latest version
now includes a "must-revalidate" Cache-control directive, which seems
to be more appropriate for what you are trying to do here. So I would
replace that paragraph with these three:
* "Cache-control: must-revalidate", which means that the
resource may be cached, but the cache must validate it before
returning it to the client.
* "Cache-control: Max-Age=0", to ``pre-expire'' a cache entry. The
resource may be cached, but the cache SHOULD validate it before
returning it to the client. However, not all caches will do so
in every case.
Because HTTP/1.0 caches ignore Cache-control directives, it might
also be appropriate to send "Expires: <a date in the past>"
(Example: Expires: Thu, 01 Jan 1980 00:00:00 GMT) to avoid
improper caching.
-Jeff
Received on Wednesday, 17 April 1996 15:35:19 UTC