W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1998

Re: ADAMS1, point 31. (cachability of methods).

From: Koen Holtman <koen@win.tue.nl>
Date: Tue, 17 Nov 1998 20:11:07 +0100 (MET)
Message-Id: <199811171911.UAA24544@wsooti08.win.tue.nl>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/258
Jeffrey Mogul:
>
[...]
>(1) In 13.4 change:
>
>   Unless specifically constrained by a cache-control (section 14.9)
>   directive, a caching system MAY always store a successful response
>   (see section 13.8) as a cache entry, MAY return it without validation
>   if it is fresh, and MAY return it after successful validation.
>
>to:
>
>   Unless specifically constrained by a cache-control (section 14.9)
>   directive, a caching system MAY always store a successful response
>   (see section 13.8) to a GET or HEAD request
>   as a cache entry, MAY return it without validation
>   if it is fresh, and MAY return it after successful validation.
>   A caching system MUST NOT treat responses to other methods
>   as cachable (by the definition in section 1.3) unless the
>   response includes Cache-Control or Expires header fields
>   implying that the response is cachable.

For the record: I support this proposed change.  This is exactly what
we need.

I don't really understand Henrik's objections, but I have the feeling
that they are based on the mistaken assumption that the above addition
specifies a top-level requirement which cannot be overridden.  The
addition actually only specifies what the default is if there is no
Cache-Control header in the response.

>-Jeff

Koen.
Received on Tuesday, 17 November 1998 11:19:46 UTC

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