W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001

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

From: Clemm, Geoff <gclemm@rational.com>
Date: Tue, 10 Apr 2001 17:36:25 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E234B@SUS-MA1IT01>
To: WebDAV Working Group <w3c-dist-auth@w3.org>
Some folks prefer to use OPTIONS for things that are true
for the whole server, and some folks just
hate live properties, but the live property is fine with me.

As for the issue of whether to marshal in a request header vs. in a
request body, a new request header eats up part of a global namespace,
whereas an XML request body can use namespaces to keep extensions
from stepping on each others toes, so I stand by my
preference for using the request body for method specific parameters
(of course, for methods like PUT that use the request body for content,
that is not an option).

Cheers,
Geoff

-----Original Message-----
From: Roy T. Fielding [mailto:fielding@ebuilt.com]
Sent: Tuesday, April 10, 2001 5:11 PM
To: Clemm, Geoff
Cc: WebDAV Working Group
Subject: Re: [offlist] WebDAV Delete post (Flavors of DELETE)


On Tue, Apr 10, 2001 at 10:41:30AM -0400, Clemm, Geoff wrote:
> 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.

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.

> 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.

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
Received on Tuesday, 10 April 2001 17:35:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:55 GMT