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

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Next message: Jim Gettys: "ADAMS1, point 28 (connection management)"
• Previous message: Larry Masinter: "RE: ADAMS1, point 31. (cachability of methods)."
• In reply to: Jim Gettys: "ADAMS1, point 31. (cachability of methods)."

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.

• Next message: Jim Gettys: "ADAMS1, point 28 (connection management)"
• Previous message: Larry Masinter: "RE: ADAMS1, point 31. (cachability of methods)."
• In reply to: Jim Gettys: "ADAMS1, point 31. (cachability of methods)."