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

In most cases, the 'cachable' constraint is not on whether
you store the value in a cache, but whether you USE the
cached value. Now, it may be foolish to cache something that
you cannot use, but perhaps not; e.g., even if the results
aren't exactly cachable, could you use delta-coding on the
next request with an appropriate entity tag?

I don't know whether it's best to say SHOULD NOT and let
implementors figure out the constraints, or to go ahead
and use MUST NOT, but to carefully redefine 'cachable' or
'cached' to mean that the cached value cannot be used,
and thus probably shouldn't be stored.

Larry
--
http://www.parc.xerox.com/masinter

> > 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 08:23:28 UTC