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: Fri, 13 Nov 1998 20:08:34 +0100 (MET)
Message-Id: <199811131908.UAA27507@wsooti08.win.tue.nl>
To: Jim Gettys <jg@pa.dec.com>
Cc: http-wg@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/228
Jim Gettys:
>
[...]
>Here's my question:
>===================
>
>Should the text for POST not in fact be a general statement for methods, 
>(saying "MUST NOT be cached", rather than "are not cachable" to make it
>crystal clear).  This would make things much more consistent, and allow
>a origin server control over what is going on).
>
>This would result in putting this sentence in secion 9:
>
>"Responses to methods other than GET or HEAD MUST NOT be cached, unless 
>the response includes appropriate Cache-Control or Expires header fields"

I believe that the spec makes the above statement somewhere already,
though I just tried to find it and failed.  Jeff?

>And removing the statements about "Response to this method are not cachable."
>in section 9.2, 9.5, 9.6, 9.7 (methods OPTIONS, POST, PUT, DELETE.)

I have always interpreted these 'are not cachable' lines as useful
reminders of the general rule I just failed to find.  Removing them
would decrease the readability of the document I think.

>Besides the cleanlyness and simplification this change would make, the 
>other big feature of this is that it makes caching behavior crystal clear 
>for extensions to HTTP - that caching is not allowed unless the server 
>marks the response cachable.
>
>Is there any danger in this I don't see?

As far as I can see making these changes does not introduce some new
danger.

>				- Jim

Koen.
Received on Friday, 13 November 1998 11:14:21 UTC

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