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

Henrik Nordstrom wrote:
> 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.

+1

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

Problem is that in many cases, the server doesn't know the URL until the 
resource is created.

A 4xx signals a client error, and in WebDAV, the response body can 
reveal additional information where to POST to instead.

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

Actually, it's also a bad choice because this should be a temporary 
redirect (== the client should keep using the original request-URI for 
the next attempt of creating a resource).

> ...

BR, Julian

Received on Monday, 20 October 2008 20:11:08 UTC