- From: Clemm, Geoff <gclemm@rational.com>
- Date: Tue, 10 Apr 2001 10:41:30 -0400
- To: "'Gary Gershon'" <gershon@celsus.net>, Bruce Williams <brucewil@pacbell.net>
- Cc: WebDAV Working Group <w3c-dist-auth@w3.org>
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