Re: [squid-users] POST cacheability

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@yahoo-inc.com