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

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:gershon@celsus.net]

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

Received on Tuesday, 10 April 2001 10:40:56 UTC