- From: Jason Crawford <nn683849@smallcue.com>
- Date: Mon, 3 Mar 2003 19:45:28 -0500
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "Clemm, Geoff" <gclemm@Rational.Com>, "WebDAV" <w3c-dist-auth@w3.org>
On Monday, 03/03/2003 at 11:08 CET, "Julian Reschke" <nnjulian.reschke___at___gmx.de@smallcue.com> wrote: > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Monday, March 03, 2003 10:44 PM > > To: WebDAV > > Subject: RE: Move and Delete (was: bind draft issues) > > > > > > > > To emphasize an earlier comment, it is true that the bind protocol > > places constraints on how a server is allowed to implement the DELETE > > and MOVE methods. In particular, a server that supports the bind > > protocol is not allowed to do a partial MOVE or a partial DELETE (even > > though 2518 allows it). > > ... > > Good catch. I remember that we discussed that at some point of time, but it > seems it was never added to the issues list. > > Our server indeed is able to support the BIND method and live properties > with all their semantics, yet won't do an atomic DELETE on collections. I > agree that *technically* a server that properly handles bindings *could* do > atomic deletes, but in reality, there may be reasons why you don't *want* > to. Saying that it doesn't support atomic deletes doesn't make sense to me. The concept doesn't exist. The binding spec's DELETE command is asking that only one thing be done. If you can't do that one thing you need to reject the DELETE request. But leaving a partial tree there is not an option because the method didn't ask you to delete those other bindings and in fact might not want them to be deleted. I would hope it's possible though and that you wouldn't have to reject the request. Even in a file system based server, I'd hope that the server could simply unmap the collection and then in the background do the delete/move of the whole tree incrementally if that were appropriate. But if it can't, IMO it needs to reject the request.
Received on Monday, 3 March 2003 19:49:42 UTC