I'm not as thrilled with the live property.  This assumes there is an actual folder, which is true fin some systems, but I'm not sure if that would be universal (e.g. Windows has a Recycle Bin icon on my desktop, but I don't have any folders with *recycle* in their name on my system).  I suppose it could be implemented as a virtual folder, where the server mimics the desired behavior of deleting.

It also requires a second operation to be performed to delete the copy from trash.  This isn't clean from a unit-of-work standpoint, particularly since the successful completion of the original delete would seem to cause the live property to vanish, which would thus make subsequently re-issuing the delete-from-trash difficult, if not impossible.  Also, when a document of a specific name is repeatedly deleted in some systems, the system adds a unique suffix to the name in trash so the file names remain unique in that folder,  It may not be possible to construct what name was assigned in trash after the original live property is gone.  All this is a real possibility if there is a communications or other client problem between the two deletes and one restarts the client.  I might see that the original file is gone, I know their is a copy now in trash, I don't know its name, and it is quite possible that I don't have permission to  just browse this shared folder looking for stuff...

The other DELETE option suggested in the original post, dealt with allowing the client to specify overwriting the file with binary information to prevent inadvertent or intentional viewing of the file.  This, of course, depends on the server having the capability to do this.  This really does need to be specified on the original request (by those who are a bit paranoid -- or those who are doing classified government work...).

I think a header is a better choice than an XML body because there are implicit deletes in doing other WebDAV requests.  A PUT deletes the original, unless some type of versioning is implemented, and (as Geoff reminds us) the body content of a PUT is already spoken for.  A MOVE may require copying to a new physical volume (such as with  a mountable file system), and deleting the original.

I like the idea of having something in the OPTIONS response to indicate the delete processing and security capabilities of the server.  The client would then know what can or needs to be sent, and, in a more extreme scenario, might decide not to store documents on this server, or to warn the human user of the implied consequences of doing so.  This would also be more honest if the administrative policy of the server is to inhibit users from deleting items from trash. (Or keeping copies somewhere despite deleting them.)  The user would know not to store his or her plans for a new .com business on this repository... or the original formula for CocaCola :)


At 05:36 PM 4/10/2001 -0400, Clemm, Geoff wrote:
Some folks prefer to use OPTIONS for things that are true
for the whole server, and some folks just
hate live properties, but the live property is fine with me.

As for the issue of whether to marshal in a request header vs. in a
request body, a new request header eats up part of a global namespace,
whereas an XML request body can use namespaces to keep extensions
from stepping on each others toes, so I stand by my
preference for using the request body for method specific parameters
(of course, for methods like PUT that use the request body for content,
that is not an option).


-----Original Message-----
From: Roy T. Fielding [mailto:fielding@ebuilt.com]
Sent: Tuesday, April 10, 2001 5:11 PM
To: Clemm, Geoff
Cc: WebDAV Working Group
Subject: Re: [offlist] WebDAV Delete post (Flavors of DELETE)

On Tue, Apr 10, 2001 at 10:41:30AM -0400, Clemm, Geoff wrote:
> On the issue of trash folders:
> HTTP headers are a poor way of marshalling method specific
> information.  A header exists in a global namespace, and should be
> reserved for things that proxies need to look at.
> So if you want to extend DELETE, I would suggest following the
> standard WebDAV approach and add an XML request body to the DELETE
> method.

Huh?  You've got that entirely backwards.  HTTP header fields are intended
to be method-specific.  The only part of an HTTP message that is not
supposed to be method-specific is the message payload (entity-headers
and entity-body).  I thought I made that perfectly clear in the HTTP spec,
but it probably got lost in the noise.

> In the specific case of trash folders, I would suggest a different
> approach.  In particular, I would add an OPTIONS parameter that would
> let you find out "where is the trash collection for this resource".
> Then the client could either issue a DELETE or a MOVE to that trash
> collection, depending on what the user wants to do.

Either the client knows where the trash is or it doesn't deserve to know
where the trash might be -- it is just another collection on the server.
Just make it an optional link in the metadata (a live property).


Gary M. Gershon  -- gershon@celsus.net  -- 203-431-9328