Subject: RE: [offlist] WebDAV Delete post (Flavors of DELETE)

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 10 Apr 2001 17:36:25 -0400

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).

Cheers,
Geoff

-----Original Message-----
From: Roy T. Fielding [mailto:[email-masked]]
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).

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 10 Apr 2001 15:20:07 -0700

> hate live properties, but the live property is fine with me.

OPTIONS is for communicating extensions and capabilities, not for
identifying the URI of a trash resource.  That is simply an external link
in hypermedia parlance.

> (of course, for methods like PUT that use the request body for content,

XML namespaces are no more capable of extensions than a global namespace
controlled by a standard.  The only difference is who gets to define them.
HTTP and XML have different design philosophies in that regard, and so
far the HTTP one has proven to be right (XML namespaces are 100% extensible,
but have almost zero interoperability success).  I'm not sure yet which
type of extensibility is better for a protocol.  I only know that needing
to parse XML in order to determine request semantics is totally and
irretrievably bad design.

Cheers,

Roy T. Fielding, Chief Scientist, eBuilt, Inc.
                 2652 McGaw Avenue
                 Irvine, CA 92614-5840  fax:+1.949.609.0001
                 ([email-masked])  <http://www.eBuilt.com>

---

From: Gary M Gershon <[email-masked]>
Date: Tue, 10 Apr 2001 18:52:47 -0400

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 :)

Gary

At 05:36 PM 4/10/2001 -0400, Clemm, Geoff wrote:

Some folks prefer to use OPTIONS
for things that are true

request body, a new request header eats up part of a global
namespace,

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).

Cheers,

Geoff

-----Original Message-----

From: Roy T. Fielding
[mailto:[email-masked]]

To: Clemm, Geoff

Cc: WebDAV Working Group

> 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,

> 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.

....Roy

--------------------------------------------------------------------------------------------------

Gary M. Gershon  -- [email-masked]  --
203-431-9328