- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 20 Oct 2008 22:30:37 +0200
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Henrik Nordstrom wrote: > On mån, 2008-10-20 at 22:12 +0200, Julian Reschke wrote: >> Henrik Nordstrom wrote: >>> Sorry. A bit tired. Didn't notice the change to POST. >>> >>> Switching to POST isn't good either. >>> >>> I'll second Brians response here. >> Which part? > > The whole message with 3 alternatives, all three of them. Proposal 2 and 3 were specific to the Vcarddav WG in general, not this specific technical issue. Proposal 1 IMHO breaks the PUT semantics (that's why I started this thread). >>> Additionally allowing for PUT to create a new resoure-URI completely >>> different from the request-URI would make sense, but needs to be >>> negotiated by a request header indicating that the client accepts this. >> Well, I proposed a new method for this in 2005, and the answer to that >> was: just use POST. And that is what AtomPub has done. >> >> So is this suddenly the wrong advice? > > It's a matter of semantics. POST is meant for application transfers, for > data being processed by the server, with no direct content mapping to > the created resource (if any). PUT is a request to store an entity > "as-is". But POST can do that as well. The only missing piece is that the client needs to know that it will. For instance in AtomPub, this is by the definition of the AtomPub collection resource. > However, creating a new method for this is defenitely not the right > thing. Better to extend PUT to allow this use case by conditionally > relaxing the target resource URI requirements, or use POST. I still do not see how this functionality can be implemented without breaking the semantics of PUT. It *can* be implemented using POST, but requires a way for the client to find out that it actually can use POST for it. That can be by contract (AtomPub), by inspection of the error response for PUT, or by some other way of discovery (WebDAV properties, Link header, whatnot). The latter cases are covered by my (currently WebDAV-specific) proposal at <http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-01.html>). BR, Julian
Received on Monday, 20 October 2008 20:31:24 UTC