RE: PUT response

["Brian Smith" <brian@xxxxxxxxxxxxxx>]

Thomas Broyer wrote:
> On Wed, Apr 23, 2008 at 8:28 PM, Nikunj Mehta wrote:
>  >  The HTTP spec states that
>  >
>  >    Responses to this [PUT] method are not cacheable.
> 
>  ...except if you include a proper Cache-Control header.

The latest HTTPbis draft just says "Responses to this method are not cacheable." for PUT.

>  I haven't gone back checking the HTTP spec, but I'd say that if the
>  response to PUT has a Content-Location header (i.e. identifies an
>  "addressable" resource) and is cacheable (i.e. contains a
>  Cache-Control header with an appropriate value) then an HTTP cache
>  might use that entity as responses to subsequent GET requests to the
>  Content-Location URI.

If the response to a PUT is cacheable, under what circumstances can the cached response be returned? RFC 2616 clearly says that a cache cannot return a cached response to a request that updates the server (PUT/POST/DELETE). Can a cached response to a PUT can be returned in response to a GET/HEAD request? I don't see anywhere that says that can be done, and presumably what is why the exception for Cache-Control/Expires was removed for PUT in the current HTTPbis draft.

The specification does not say what the entity represents in a "200 OK" response to a PUT request, so I avoid returning "200 OK" for PUT (I always return 201 or 204). If the client wants to update a resource and retrieve the new version in a single round-trip, it can use HTTP pipelining or the non-standard batching method of its choice to combine a PUT and a GET request.

Regards,
Brian