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: Brian Smith <brian@briansmith.org>
Date: Mon, 20 Oct 2008 13:22:32 -0500
To: <julian.reschke@gmx.de>, <ietf-http-wg@w3.org>
Message-ID: <009e01c932e0$d3eda600$7bc8f200$@org>

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

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

- Brian
Received on Monday, 20 October 2008 18:23:03 GMT

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