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 20:39:53 +0200
Message-ID: <48FCD079.1080207@gmx.de>
To: Brian Smith <brian@briansmith.org>
CC: ietf-http-wg@w3.org

Brian Smith wrote:
> Julian wrote:
>> "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
> 
> I think this is better, according to what you quoted above:
> 
> S: HTTP/1.1 301 Moved Permanently
> S: Location: /folder/bar
> S:
> S: Do it there
> 
> C: PUT /folder/bar
> C: ...

Of course that's not going to work in practice, as Cyrus pointed out. We 
want to help servers that generate the URL based on the underlying 
persistence, so the server really can't predict the final URL until the 
resource is created.

>> C: POST /folder
>> C: Host: ...
>> C:
>> C: Content
> 
> It is a bad idea to switch to POST just for this. There is already a
> standard way of making PUT idempotent but there is no standard way of making
> POST idempotent, and you can easily recover from a broken connection with
> PUT (just HEAD the same URI; if you get the old validators, issue another
> Conditional PUT). However, there's no standard way to recover from a failed
> connection during POST.
> 
> If anything, more applications should be switching from POST to PUT.

Well, do you have a proposal that uses PUT as allowed by the RFC2616, 
and works for the above use case?

BR, Julian
Received on Monday, 20 October 2008 18:40:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:56 GMT