Re: is DELETE "best effort"?

This topic is currently being hotly debated in the thread:
"WebDAV Bindings - Issue Yaron.AtomicDelete"

Although 2518 currently implies "yes", the authors of the BIND protocol
extension have proposed that the answer be changed to "no".  Stay tuned (:-).

Minimally, we shall insist that a server be *allowed* to
leave all member collections unmodified if it cannot delete
the collection specified in the DELETE request.

Cheers,
Geoff

   From: Yaron Goland <yarong@Exchange.Microsoft.com>

   Yes.

   > -----Original Message-----
   > From: bill@carpenter.ORG [mailto:bill@carpenter.ORG]
   > Sent: Thursday, January 27, 2000 11:46 AM
   > To: w3c-dist-auth@w3.org
   > Subject: is DELETE "best effort"?
   > 
   > 
   > RFC-2518 doesn't come right out and say so, but I think it implies
   > that a DELETE on a collection is on a "best effort" basis, where you
   > can deduce what got DELETEd versus what didn't (and why) from a
   > possible multistatus response.
   > 
   > Suppose I request a DELETE of /zoo/, where /zoo/ contains /zoo/mammals
   > and /zoo/birds.  Suppose there is a problem with the DELETE of
   > /zoo/mammals (it's locked by my corporate rival, Snidely Whiplash).
   > Should the server, having discovered this, go ahead and attempt a
   > DELETE of /zoo/birds?
   > 
   > Section 8.6.2 says that if you can't DELETE a resource, you shouldn't
   > DELETE its ancestors (for the sake of namespace consistency).  It is
   > silent on what you should do about the resource's siblings, though
   > (the example in 8.6.2 isn't bushy enough to show it).  There is a hint
   > that some of the DELETEs may be allowed to succeed while others fail
   > in that 204 response codes are to be omitted from the multistatus
   > because they are the default success code.
   > 
   > Is DELETE intended to be "best effort"?
   > -- 
   > bill@carpenter.ORG   (WJCarpenter)           PGP
   > bill@bubblegum.net                    0x91865119
   > 38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3
   >

Received on Thursday, 27 January 2000 17:02:02 UTC