W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

Re: NEW ISSUE: Methods and Caching

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 17 Nov 2008 16:22:13 -0600
Cc: <henrik@henriknordstrom.net>, <Robert.Siemer-httpwg@backsla.sh>, <ietf-http-wg@w3.org>
Message-Id: <761B7C3D-96D4-4DC0-94E5-F8E7FD080C94@mnot.net>
To: Brian Smith <brian@briansmith.org>

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     http://www.mnot.net/
Received on Monday, 17 November 2008 22:22:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:47 UTC