Subject: is DELETE "best effort"?

From: [email-masked] (WJCarpenter)
Date: Thu, 27 Jan 2000 11:45:51 -0800

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"?
-- 
[email-masked]   (WJCarpenter)           PGP
[email-masked]                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3

---

From: [email-masked]
Date: Thu, 27 Jan 2000 17:48:49 -0500

That was my interpretation.

[email-masked] (WJCarpenter)@w3.org on 01/27/2000 02:45:51 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:

Subject:  is DELETE "best effort"?

---

From: Yaron Goland <[email-masked]>
Date: Mon, 31 Jan 2000 16:50:27 -0800

I agree that there is an issue here that requires further clarification.

The key here is user expectation. When a user issues a DELETE they need to
know if the result is either going to be a best effort delete or an atomic
delete. They need to know this before they issue the command, without this
knowledge then they can never be sure what the result of the command is.

For example, imagine a program that can walk a tree of source code, change
all the ACLs so as not to give the current user write permission to those
files and then start to compile the source code into various bits and pieces
of code, inside the local collections, before linking them together. When
the final result is done the program will then issue a depth infinity DELETE
in order to clean up. Because the ACLs have been changed the program is
counting on the fact that the only thing that will be deleted will be the
code files. However in a world where best effort isn't guaranteed the
program's assumption can fail. The server may refuse the DELETE because it
can't successfully delete all the files atomically (due to the ACLs) 

This means, in practice, programs must ALWAYS assume the absence of best
effort. This means that WebDAV will be inefficient since clients will be
required to issue individual deletes for all possible files. 

The previous situation is the worst of both worlds. Clients that need
best-effort can't depend on getting it so they must do file by file deletes.
Additionally clients that really want atomic behavior can't depend on
getting it so they will also have to do file by file deletes, although they
could try a depth delete first and then follow up with file by file if there
was an error. The race conditions and performance problems introduced by
file by file deletes (even with pipelining) are unacceptable.

Therefore I believe that the best effort issue identifies an
interoperability problem with WebDAV. We need to either guarantee best
effort or guarantee atomicity. But the current situation in which it could
be either is just a mess.

For reasons that seem to have already gained consensus we can not mandate
atomic delete. Therefore we are left with mandating best effort. Those
clients who wish to guarantee atomic delete behavior will need to use the
MAN mechanism with the DELETE method.

Therefore I propose that when we rev WebDAV we put in language mandating
best effort deletes.

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:[email-masked]]
> Sent: Thu, January 27, 2000 7:18 PM
> To: [email-masked]
> Subject: Re: is DELETE "best effort"?
> 
> 
> 
>    From: Yaron Goland <[email-masked]>
> 
>    Bill the answer for RFC 2518 is an unequivocal YES.
> 
> What concerns me is that the sequence:
> 
> "Is DELETE best effort?  YES."
> 
> will result in people believing that DELETE *must* be best effort,
> i.e. a server is required to delete everything it can, even 
> if it actually
> knows (or could easily find out) that it cannot delete everything.
> 
>    What is being argued is if we should change that YES to a 
> no. This will
>    require issuing a new version of RFC 2518.
>    Until such a new version is issued the answer is YES.
> 
>    BTW, Geoff, RFC 2518 already supports having the server 
> refuse to change any
>    of the members if it can't delete the root.
> 
> I agree that this behavior is not forbidden by rfc2518, but I also 
> believe some implementors will misinterpret in one direction 
> (i.e. DELETE 
> must be all or nothing) or in the other direction (i.e. DELETE must
> be best effort), so whatever answer we arrive at, we should make sure
> it is clearly stated in the next rev of rfc2518.
> 
> Cheers,
> Geoff
>