RE: NEW ISSUE: Methods and Caching

On Tue, 18 Nov 2008, Henrik Nordstrom wrote:

> The classic example of where a cacheable response to POST makes sense is
> the guestbook example (or unmoderated blog comments for those needing a
> more modern example, basically the same thing in a different era) where
> the visitor POSTs an addition to the page currently viewed, or "separate
> entity that accepts annotations" as it's expressed in the RFC. The
> response given to the POST is the new representation of the page. Both
> GET and POST uses the same URL in this example.
>
> So you have the sequence
>
>  GET /page
>
>  200 OK, max-age=X
>
> [user fills in comment form]
>
>  POST /page
>
>  200 OK, max-age=X
>
> where the 200 OK response to POST is in all regards identical to that of
> a GET following the POST.

How about

GET /page

200 OK

POST /page

303 Location: /page

GET /page

Of course it requires another round trip, but it's far more clear.

> Note that the POST request as such can never be satisfied from cache. A
> repeated POST with the same form content will not yield the same result
> even if the response is cacheable.

I've always read cachable POST as "if I have the same URI+payload, then
the server told me I can serve from the cache", now having the "let's 
cache POST responses for other methods would require explicit signalling. 
The 303 on the same page + cache info + etag might signal that, but 
currently that's stretching the meaning of methods a lot.

> This only applies when the response to POST has explicit expiry
> information as the response to POST has the duality of either being a
> status message indicating the result of the action OR the modified
> resource, both using the 200 OK status code. There was a discussion some
> time ago about adding a new status code to separate the two cases to
> make this property of POST more explicit, but iirc the conclusion were
> that 200 OK is actually fine for both cases. But this property of POST
> do need a better explanation.
>
> PUT on the other hand is not really meant to perform any server-side
> processing of the resource, only storing it "as-is" and adding relevant
> meta data such as ETag (which returned in the response) and Content-Type
> if not supplied by the client (not returned in the response). For all
> practical purposes (i.e. continued authoring of the resource) the client
> SHOULD be able to use the resource it sent in the PUT request as it's
> current representation of the resource, even if it may differ slightly
> from what the server actually stored. Because of this the response to
> PUT is always a status message. There has been discussions about
> extending PUT to allow it to return a modified representation, and any
> such negotiated extension would place those responses in the same family
> as POST above, returning a representation that is a valid representation
> as if the request had been a GET request immediately after the PUT.
>
> Regards
> Henrik
>
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves