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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 20 Oct 2008 16:30:10 +0200
Message-ID: <48FC95F2.90602@gmx.de>
To: HTTP Working Group <ietf-http-wg@w3.org>


and old discussion just started again over on the vcarddav mailing list...

Is the following server behavior a legal interpretation of PUT semantics?

C: PUT /folder/foo
C: Host: ...
C: Content

S: HTTP/1.1 201 Created
S: Location: /folder/bar

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.

Looking at the *method* definition of PUT, this is totally an abuse of PUT:


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


"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: Content

S: HTTP/1.1 4xx
S: You can't do that

and instead

C: POST /folder
C: Host: ...
C: Content

S: HTTP/1.1 201 Created
S: Location: /folder/bar

Feedback appreciated,

Received on Monday, 20 October 2008 14:30:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:47 UTC