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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Point! Good security practice is to "firewall" and not reveal too
much.
A subsystem that "tells all" is frowned upon by at least some admins.

Good practice in standards development is to find the "least" that
has to be
defined. Why does this can of worms have to be opened? 

What is the minimal functionality needed and why? Just asking. :-)
If we are VERY clear on what we have to do, we will find a way
to do it, I guess. Otherwise we will "what if" forever.

Bruce Williams            brucewms@pacbell.net
- ----------------------------------------------------------------------
- --
Hic locus est ubi mors gaudet succurrere vitae

- ----- Original Message -----
From: "Roy T. Fielding" <fielding@ebuilt.com>
To: "Clemm, Geoff" <gclemm@rational.com>
Cc: "WebDAV Working Group" <w3c-dist-auth@w3.org>
Sent: Tuesday, April 10, 2001 6:54 PM
Subject: 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>
>

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBOtO/eXuDB3/hEB6MEQKFVgCg16VZq1mAjQkaZlRmqVsO+Z9a9XUAniDV
xEQXkvPscz8Pw79CescwFIe0
=vHDN
-----END PGP SIGNATURE-----

Received on Tuesday, 10 April 2001 22:22:16 UTC