Re: server applying PUT to a resource other than the request-URI

On mån, 2008-10-20 at 16:30 +0200, Julian Reschke wrote:

> That is, the server stored the information, but not at the request-URI, 
> and tries to inform the client via the Location header that the content 
> actually was stored somewhere else.

The "not at the request-URI" part worries me.

201 Location in response to PUT is not meant to be used like this. It's
more meant in the case like when the created resource-verstion gets a
persistent URL, or when the request-URI is a usable URI for the resource
but not the preferred URI. GET requests to the request-URI just after
the PUT should return the stored resource, even if 201 did indicate
another preferred location.

> Looking at the *method* definition of PUT, this is totally an abuse of PUT:
> 
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-04.html#rfc.section.8.6>:
> 
> "The PUT method requests that the enclosed entity be stored at the 
> supplied Request-URI. If the Request-URI refers to an already existing 
> resource, the enclosed entity SHOULD be considered as a modified version 
> of the one residing on the origin server. If the Request-URI does not 
> point to an existing resource, and that URI is capable of being defined 
> as a new resource by the requesting user agent, the origin server can 
> create the resource with that URI. If a new resource is created at the 
> Request-URI, the origin server MUST inform the user agent via the 201 
> (Created) response. If an existing resource is modified, either the 200 
> (OK) or 204 (No Content) response codes SHOULD be sent to indicate 
> successful completion of the request. If the resource could not be 
> created or modified with the Request-URI, an appropriate error response 
> SHOULD be given that reflects the nature of the problem...."
> 
> and
> 
> "In contrast, the URI in a PUT request identifies the entity enclosed 
> with the request -- the user agent knows what URI is intended and the 
> server MUST NOT attempt to apply the request to some other resource. If 
> the server desires that the request be applied to a different URI, it 
> MUST send a 301 (Moved Permanently) response; the user agent MAY then 
> make its own decision regarding whether or not to redirect the request."
> 
> IMHO the *right* thing to do is:
> 
> C: PUT /folder/foo
> C: Host: ...
> C:
> C: Content
> 
> S: HTTP/1.1 4xx
> S:
> S: You can't do that


Why 4xx. A redirect to the URI where the resource may be stored is more
appropriate.

Hmm.. the text in PUT should be fixed as well.. 301 is not a good redirect code to use there due to the amount of broken implementations..

> and instead
> 
> C: POST /folder
> C: Host: ...
> C:
> C: Content
> 
> S: HTTP/1.1 201 Created
> S: Location: /folder/bar

No. See above.

REgards
Henrik