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

On Tue, Apr 10, 2001 at 06:45:11PM -0400, Clemm, Geoff wrote:
> Well, since we've got Roy's attention (:-) ...

DAV always has my attention -- I just don't usually have time to argue.
Right now I am procrastinating from doing my taxes.

> If your server does DELETE's to a trash collection (instead of making
> it totally disappear), wouldn't that fall under the "capabilities"
> of your server?  And if your server maintains that trash collection
> at a fixed location (for all resources on that server), why would that
> be unreasonable/bad information to include in the OPTIONS response
> (I am assuming that we give OPTIONS a request body in which the 
> client indicates what OPTIONS information it is interested in).

The fact that a server runs on a Pentium III 500MHz CPU falls under
"capabilities" too, but that doesn't mean that an OPTIONS message should
advertize it as such.  OPTIONS was intended for info that defines the
interoperability mechanisms available at the server/resource.
It would have been better defined as a PROPFIND that returned a property
consisting of a link to a URL space containing configurable options as
resources, but OPTIONS predates properties by a long shot.  Alternatively,
we could stick a fork in this subject by deprecating PROPFIND and just
using OPTIONS for all property retrievals.  I bet that would be popular.

> To emphasize, I don't advocate this approach (i.e. live properties are
> fine with me), but the topic has been raised in several threads, and I
> haven't seen a convincing argument either way.  (Note: There has been
> no lack of definitive statements ... but unfortunately the definitive
> statements from different people have not agreed with each other :-).

Okay, let's try one.  Is it possible for a web server to have multiple
trash cans?  Yes -- that is a resource implementation issue -- the
resource URI hierarchy visible to the client may span hundreds of
separate systems/disks/virtual spaces behind the web server interface.  
So, from an interoperability standpoint, it is pointless to ask the
server itself (without using a URL) for a reference to a trash can
for all of its resources.  Therefore, the relationship between a resource
and its potential trash can must be resource-specific.  That means it
is either a property of the resource or a property of a container of
that resource (which, by inference, makes it a property of the resource).

So it can be a live property or a dead property. If we make it a dead
property, then a client is allowed to set its value, which is something
that could be considered a security problem if the server isn't careful
about checking the value.  OTOH, it might be useful if we wanted to
define a distributed trash can protocol, wherein the server POSTs the
content to the trash can resource as part of the DELETE. *shrug*
Of course, access control on that property becomes an issue, but that
would lead me down the rathole of why the set of properties of a
resource are themselves resources ...

We are then left with the question of what is the most appropriate
mechanism for revealing a property of a resource to the client of a
webdav server?  If the answer is not PROPFIND, then why should any other
property be retrievable via PROPFIND?

Regarding the trash can itself, it is either accessible to clients
as a resource or not accessible at all (because there is no such thing
as accessing something other than a resource on the Web).  If it is a
resource, then what kind of resource is it?  I suppose it could be
anything, but if we want the trash can to be browsable like any other
DAV resource space (as is the case for Macintosh and Windows trash cans),
then the only reasonable choice is a collection resource.  Otherwise
we'd have to define a completely new protocol standard for interoperating
with trash cans, for which I doubt we can find any volunteers.

So, the right protocol is to allow each resource to have an optional
property that is a link to a collection resource that can be operated
upon as a trash can, with appropriate access control.

> On the separate topic of header vs. method body, although it is
> clear that method semantics of concern to a proxy should be in
> headers (so that the proxy doesn't need to process the body),
> could you motivate why the detailed request semantics needed only
> by the resource implementation shouldn't appear as XML (WebDAV
> seems to work reasonably well with request bodies like PROPPATCH
> in XML).  Is it important for a proxy to know whether or not a 
> DELETE'd resource has been copied/moved to a trash collection?
> Or is it some other argument against XML (XML parsers are pretty
> trivial).

Application-level semantics need to be visible for any intermediary,
not just proxies.  How does the client know that it is talking to
the origin server?  For this specific request semantic, it probably
doesn't matter because the effect on intermediaries is already covered
by the method name.  However, what you stated earlier was a general
principle, which caught my eye because your description contradicts one
of the design principles of HTTP that I described in my dissertation.

As you probably noted, I get a little annoyed whenever webdav contradicts
my dissertation, regardless of whether or not it is the right solution.  ;-)

Back to the original question, I don't see any reason to allow the client
to choose whether or not the DELETE goes to the trash can.  A trash can is,
after all, just a poor man's form of version control.  I think it should be
set as part of the configuration of a containing collection resource,
either by the server internals or by linking to a resource on the server
that knows how to be a trash can.

Cheers,

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

Received on Tuesday, 10 April 2001 21:57:48 UTC