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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 20 Oct 2008 22:10:14 +0200
Message-ID: <48FCE5A6.8060808@gmx.de>
To: Henrik Nordstrom <henrik@henriknordstrom.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>

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.


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

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