- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Mon, 20 Oct 2008 22:44:15 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-Id: <1224535455.13334.8.camel@henriknordstrom.net>
On mån, 2008-10-20 at 22:30 +0200, Julian Reschke wrote: > 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). Not if negotiated imho. > 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. POST can do anything any other method can do. It's just a matter of defining the context. > I still do not see how this functionality can be implemented without > breaking the semantics of PUT. Maybe. Not so sure. Depends on what one puts into the strict semantics of a 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>). I don't like relying on round-trip discovery and application protocols for simple storage, especially for use cases like "I want to store this at this approximate location". And not having support for this family of requests opens up for a myriad of different POST protocols for performing this kind of action. There is already too many of those. Regards Henrik
Received on Monday, 20 October 2008 20:45:04 UTC