Re: NEW ISSUE: Methods and Caching

AIUI it's implied by the combination of POST being explicitly  
cacheable, but being required to be written through. Freshness can't  
be used, and validation is fraught with difficulty.

Note that PROPFIND is in the same boat as POST; it's defined as being  
cacheable, but since write-through isn't explicitly relaxed for it,  
this isn't terribly useful.

On 17/11/2008, at 10:03 AM, Brian Smith wrote:

> Henrik Nordstrom wrote:
>> On sön, 2008-11-16 at 04:34 +0100, Robert Siemer wrote:
>>> Same people like to have a POST response cached for the next GET to
>>> come, but this effect can be achieved by better means:
>> It's already defined so in HTTP/1.1 (and 1.0). Or do you propose
>> removing this feature from the specification os POST?
> I searched through RFC 2616 for a long time trying to find this.  
> Where is it specified that a cached POST response can be returned  
> for a subsequent GET request?
> - Brian

Mark Nottingham

Received on Monday, 17 November 2008 22:22:51 UTC