Re: HTTP/1.1 Issue: max-age in responses not defined
Koen Holtman (koen@win.tue.nl)
Mon, 31 Mar 1997 17:54:55 +0200 (MET DST)
Roy T. Fielding:
>
>After some good comments from Jeff, I am changing my proposed change.
[...]
>should be replaced with
[...]
> Many HTTP/1.0 cache implementations will treat an Expires value that
> is less than or equal to the response Date value as being equivalent
> to the Cache-Control response directive "no-cache". If an HTTP/1.1
> cache receives such a response, and the response does not include a
> Cache-Control header field, it SHOULD consider the response to be
^^^^^^
> non-cachable in order to retain compatibility with HTTP/1.0 servers.
^^^^^^^^^^^^
Eek! This is a completely new SHOULD as far as I can see.
I oppose adding this SHOULD because it leads to sub-optimal caching. I
don't see any need to be compatible with the `Many HTTP/1.0 cache
implementations' the paragraph talks about. I consider these `many
implementations' to be sub-optimal, because they should be using I-M-S to
revalidate the stale entry instead of just throwing it away.
Also, this new SHOULD contradicts the Expires section:
|14.21 Expires
|
| The Expires entity-header field gives the date/time after which the
| response should be considered stale. A stale cache entry may not
| normally be returned by a cache (either a proxy cache or an user
| agent cache) unless it is first validated with the origin server [...]
> ...Roy T. Fielding
Koen.