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: Tue, 21 Oct 2008 08:29:36 -0700
Message-Id: <8A7DAEF1-1CD7-409E-8E13-06928973E1BC@gbiv.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

On Oct 20, 2008, at 11:39 AM, Julian Reschke wrote:
> 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.

No, we don't want to help those servers.  Why help bad design?

The whole premise of this question is just silly. If the server
doesn't intend to support PUT on a given URI, then it won't be
allowing PUT on that URI in the first place; it will be directing
the client to POST.  If the server actually does accept PUT on a
given URI and is simply creating aliases for other things (like
Slug-based permalinks), then that doesn't need to be noted in the
response -- both resources still exist, both allow PUT, and the fact
that one's state overlaps with another is simply irrelevant to
the protocol.

The answer is that if PUT is used and the server needs to redirect
the request, then redirect with 307.  Any other response in that case
is not compliant with HTTP.  If the server doesn't want that to happen
then it will offer a POST interface instead, just like the spec says.

....Roy
Received on Tuesday, 21 October 2008 15:30:16 GMT

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