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: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 23 Oct 2008 01:55:54 -0700
Message-Id: <129ABA83-D85F-4BFF-8CD8-CFB91E1CF457@gbiv.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

On Oct 22, 2008, at 11:37 PM, Julian Reschke wrote:
> But in this case a temporary redirect is actually needed. If the  
> client gets a 301, it potentially use the URI given in Location:  
> for all subsequent request, and that's definitively not what people  
> want in this case.

In that case, use of PUT is not an option.  PUT implies that the client
wants to use that URI.  301 is saying that they can't use that URI, but
they should try using this other URI for the *same resource*.

It seems to me that their use case requires POST.  Why is that a  

>> ...
>>> I would have thought that a 4xx status code such as 405 Method  
>>> Not Allowed (server does understand PUT, but not on this URI) or  
>>> 409 Conflict (current state of the resource conflicts with the  
>>> request) would be adequate?
>> It might be.  It largely depends on what you consider to be adequate,
>> whether you want the client to offer redirection to the user, and if
>> the client properly displays the body of the response to explain
>> what just occurred.  Each response gives the client some idea of how
>> (or if) the problem can be fixed.  The only fix that can be automated
>> is the one for 301, which is why that is defined in a way that can
>> be automated (if the user agrees or has preconfigured their client
>> to follow that redirect).
>> Personally, I would code the server to accept the resource as defined
>> by the client and then create a 302 binding for the slug URI.  But
>> that's just me.  There is no single way to do this in HTTP and there
>> is no need for one because the response tells you what worked.
> That approach would work, but still requires the server to persist  
> the names chosen by the client. I'm not saying this is bad, but it  
> was the claim that some servers couldn't do that started this  
> discussion.

I don't believe that claim.  If they can store data, they can save  

> Right now some work around their problem by accepting the PUT (with  
> 201), but storing the resource under a different URI, and it seems  
> to me that this a bad idea (given the PUT semantics defined in HTTP).

It isn't allowed by HTTP for that reason.

Received on Thursday, 23 October 2008 08:56:30 UTC

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