ADAMS1, point 31. (cachability of methods).

Query to the list on something more than usual in the editorial
process:

Glenn asks: 

> 
> 31. Section 9.2., pg. 49, 2nd para., states "Response to this method are
> not cachable." Should this be made stronger with either MUST NOT or
> SHOULD NOT?
> The same comment applies in a variety of other context regarding the
> suitability or non-suitability of caching a response.

This problem occurs in section 9.2, 9.5, 9.6, 9.7 (methods OPTIONS,
POST, PUT, DELETE.

At first blush, it would seem that Glenn's MUST NOT suggestion would
be best.

But...

POST says:

"Responses to this method are not cachable, unless the response includes
appropriate Cache-Control or Expires header fields. "

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"

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.)

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?
				- Jim

Received on Friday, 13 November 1998 07:16:15 UTC