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