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

RE: NEW ISSUE: Methods and Caching

From: Brian Smith <brian@briansmith.org>
Date: Tue, 18 Nov 2008 06:39:40 -0600
To: <mnot@mnot.net>
Cc: <henrik@henriknordstrom.net>, <Robert.Siemer-httpwg@backsla.sh>, <ietf-http-wg@w3.org>
Message-ID: <013b01c9497a$bab7b850$302728f0$@org>

Mark Nottingham wrote:
> AIUI it's implied by the combination of POST being explicitly
> cacheable, but being required to be written through.

It looks like something that was just overlooked to me. It almost never
makes sense for the response to a POST to be returned for a GET request to
the same request URI. It would be more useful for PUT (e.g. an AtomPub
server could return a new representation of the entry in its response to a
PUT).

I interpreted the combination of the write-through requirement and POST
being cacheable like this: if the response to the POST indicates that a
cached response can be returned without validation, then write-through isn't
required as long as that response is fresh--in other words, it is a way of
indicating that write-through isn't required. This makes sense because there
are a lot of cases where people use POST as a query mechanism (e.g. due to
real or imagined limitations on request URI length). It also explains why
POST is cacheable but PUT isn't; PUT is explicitly defined to modify a
resource, whereas POST isn't.

> 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.

PROPFIND is explicitly defined as being safe, so write-through isn't
required. (Write through is required only for "methods that might be
expected to cause modifications to the origin server's resources.")

- Brian
Received on Tuesday, 18 November 2008 12:40:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:57 GMT