W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1997

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

From: Koen Holtman <koen@win.tue.nl>
Date: Mon, 31 Mar 1997 17:54:55 +0200 (MET DST)
Message-Id: <199703311554.RAA09526@wsooti08.win.tue.nl>
To: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2957
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

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:01 UTC