- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 28 Feb 2012 23:54:37 +0100
- To: Amos Jeffries <squid3@treenet.co.nz>
- CC: Martin Thomson <martin.thomson@gmail.com>, "Roy T. Fielding" <fielding@gbiv.com>, ietf-http-wg@w3.org
On 2012-02-28 23:16, Amos Jeffries wrote: > On 29.02.2012 07:31, Martin Thomson wrote: >> On 27 February 2012 13:23, Roy T. Fielding <fielding@gbiv.com> wrote: >>> No, POST can create resources. The only difference is that the >>> client doesn't >>> know how the resource(s) will be identified after being created. >> >> And some of us really like having some control over our own URI space, >> preferring this approach over PUT. I wouldn't characterize that as a >> mistake, just a choice. > > > The blessed way to do that is with a 3xx redirect instructing the client > where you want the resource PUT if they somehow get it wrong. (Or just I wouldn't call it "the blessed way". In particular, automatically following a redirect upon PUT might be dangerous. > plain denying wrong PUT if you dont want third-party scripts using PUT > on your site.) Yes. If you want to control the URI space, simply do not implement PUT-for-create. > Yes, I too see a bandwidth problem with that blessed way of doing > things. Perhapse what is needed is a response indicating "okay, but > change the URI to X" which does not involve a repeated PUT action. The > plain PUT+200 sequence seems not to do that easily (workable ideas > welcome. With my web-dev hat on I have an interest in implementing). So you want PUT semantics with server-chooses-URI? I tried to specify this a few years ago (http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-latest.html) but was "convinced" that POST is sufficient, so defined the WebDAV-specific RFC 5995. Best regards, Julian
Received on Tuesday, 28 February 2012 22:55:15 UTC