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

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 10 Apr 2001 10:41:30 -0400

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.

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.

Cheers,
Geoff

   From: Gary Gershon [mailto:[email-masked]]

   ...
   I think a bit of background on my suggestion that we have an
   additional WebDAV HTTP header for delete processing would clarify
   its goals:

   I've been working on enterprise WebDAV implementations for the last
   year, primarily using the Xythos server.  Xythos provides a very
   handy option to allow deleted files to be automatically stored in a
   trash folder associated with the particular root directory.  This
   is great for the "oops" factor where one wants to recover a deleted
   file, and complements their automatic versioning facility.

   Other implementations, of course, have different schemes, and this
   is why it would be good to be able to express the original DELETE
   request more fully in WebDAV.

   We have four use cases where we do not want this trash-foldering to
   happen:

   1.  The user wrote something (perhaps in haste, or perhaps
       something that was confidential) that he/she does not want to
       be subsequently read by others either within the organization,
       or through the legal discovery process.

   2.  The document was being added by a program within a long-running
       unit-of-work and we want to do a rollback, rather than a
       commit, after it has already been stored and committed to the
       document server.  Here we want to avoid wasting space.

   3.  Documents are being moved to long-term archive storage and
       deleted from the operational system to free space.  This is
       done by a records retention application on a recurring (perhaps
       yearly) basis.  By definition, we want to delete it completely
       from the operational system.

   4.  The user was using the file system to hold documents (and
       versions) temporarily as work-in-process.  When the document is
       deemed finished ("Published") the temporary work products
       should not be retained.

   We like having the trash folder, so our current "work-around" to
   permanently delete a document is to issue two deletes.  First for
   the document, and then for the trash folder copy.  This requires
   the client (human or application) to know about the trash folder
   and have permission to delete stuff from it.

   It would be better if a single DELETE could communicate the entire
   request.  This avoids having the client know the structure of the
   repository, have access to the trash folder, and avoids
   unit-of-work problems when multiple requests are required to
   fulfill the delete process.

   ...

   By adding a new delete header, the goal would be to have WebDAV
   fully communicate the client's intent in a single HTTP request.
   How the server honors the request depends on the implementation.
   If the installation is using a programmable server then they can
   customize this behavior to satisfy their business requirements.

   I think an environment of appropriate security can thus be built
   using WebDAV.  I don't view the 'trash' folder as an OS flaw, but
   as a capability that serves to benefit the user community.  It
   needs to be implemented and managed to meet business document
   retention requirements, and also eliminate the potentially wasteful
   accumulation of truly dead documents.  Bruce, I think you are quite
   correct, if we are to have a secure environment, it will indeed
   take a overt effort to this end, and this requires a thoughtful
   technical implementation of WebDAV clients and servers.

   Gary

   At 11:12 PM 4/8/2001 -0700, you wrote:

   Gary,

   The delete, delete from trash, clear sectors on disk options you
   made reference to brings up something I have always been unclear
   about - what is the 'security' level required/provided by WebDAV?
   As the range of options you mentoned show, this is a classic
   "slippery slope".  Where does it end?

   I believe many activities delete and leave items in the 'trash'.
   This can in some ways be viewed as a design flaw in the OS, or at
   least a flaw at some level of desired security. And this is the
   point - - if the desired level of security is above that provided,
   in general, by the OS - are we to attempt to make up for this?

   If we are to produce a 'secure' enviroment, ( not a bad thing! ), I
   believe it will take a overt effort to this end. Otherwise, we will
   just introduce complications here and there as we "see problems" to
   no real overall gain.

   But what do I know? :-)

---

From: John Stracke <[email-masked]>
Date: Tue, 10 Apr 2001 12:59:35 -0400

> reserved for things that proxies need to look at.

It *might* be useful for a proxy to know that a resource has been moved
to a trash folder--it can update its cache.  On the other hand, looking
through the trash folder isn't going to be all that common.

Uh...ah! And the HTTP/1.1 definition of DELETE semi-forbids moving the
resource to a trash folder that can be accessed via HTTP:

     the server SHOULD NOT indicate success unless, at the time the
     response is given, it intends to delete the resource or move it
     to an inaccessible location.

(RFC-2616, section 9.7, first paragraph.)

> standard WebDAV approach and add an XML request body to the DELETE

It might also be useful to have a response body, to indicate what action
was actually taken.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"The avalanche has already started. It is too|
[email-masked]|late for the pebbles to vote." --Kosh        |
\==============================================================/

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 10 Apr 2001 09:11:24 -0700

Geoff,

Good suggestion about marshalling in the body rather than the headers.  But
the DELETE/MOVE choice won't work.

The problem is that choosing the default behaviour means working with
clients that are minimally DAV compatible, and that means that one maps the
request that those clients are going to make (DELETE) to the default
behaviour.  One puts the onus on clients that understand the difference to
make the special request (DELETE + I-mean-it-really-blow-it-away).

Ugly, but that's the kind of compromise one has to make when designing a
protocol piece by piece.  It's the price we pay for having been able to
finish DAV when we did rather than 10 yrs from now :)

lisa

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Tuesday, April 10, 2001 7:42 AM
> To: 'Gary Gershon'; Bruce Williams
> Cc: WebDAV Working Group
> Subject: RE: [offlist] WebDAV Delete post (Flavors of DELETE)
>
>

---

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

> standard WebDAV approach and add an XML request body to the DELETE

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.

> 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