Re: HTTP/1.1 Issue: max-age in responses not defined

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.

Received on Monday, 31 March 1997 07:56:40 UTC