- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 17 Nov 2008 16:22:13 -0600
- To: Brian Smith <brian@briansmith.org>
- Cc: <henrik@henriknordstrom.net>, <Robert.Siemer-httpwg@backsla.sh>, <ietf-http-wg@w3.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