RE: NEW ISSUE: Methods and Caching

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 UTC