Well, the relevant part is:
Section 9.5
Responses to this method are not cacheable, unless the response
includes appropriate Cache-Control or Expires header fields.
However, the 303 (See Other) response can be used to direct the
user agent to retrieve a cacheable resource.
Further down (e.g., in 13.6), there is only reference to using the
URI and the selecting request-headers as input into the cache key,
never the method.
Effectively, the POST response is, by default, a status message, but
if it's allowed to be cached, it becomes a representation of that
resource, and available to GET.
This area isn't documented very well, no matter which way you
interpret it. It should be cleaned up.
Overall, caching POST responses would be nice. If I were
prioritising, however, I'd be much more excited about getting Squid
conformant to section 13.10 (invalidations from side effects).
Cheers,
On 2006/10/17, at 2:24 PM, Henrik Nordstrom wrote:
mån 2006-10-16 klockan 22:17 -0700 skrev Mark Nottingham:
That's been my understanding of it for many years, and I've heard
others say likewise.
Been reading the RFC up and down, and can't in my way of reading it
find
any support for this, only the opposite.
Please clue me in on the reasoning here, from the point of the RFC.
If a server wanted to say "Please don't POST to this URI", they could
just respond with a 405 Method Not Allowed. 4xx responses have a
"don't do that again" semantic anyway...
For a single request yes. But the semantics for a shared cache is
not as
well defined.. so we use the general bailout of "responses may be
cached
unless indicated otherwise" in Squid..
Regards
Henrik
--
Mark Nottingham
mnot@xxxxxxxxxxxxx
