Re: DELETE in WebDAV Advanced Collections

>This definition appears, on the surface at least, to contradict RFC 2068,
>which says that the methods defined there apply to resources.  For DELETE,
>it says, "The DELETE method requests that the origin server delete the
>resource identified by the Request-URI."  (It also says that the client
>should not assume that the operation has been carried out, even if a success
>status code is returned, so that may give us some room to maneouver.)
>
>RFC 2518 explicitly states that a DELETE must result in the removal of all
>URIs from their collections for the resource identified by the request-URI.

Keep in mind that the web's model upon which RFC 2068 was based defines
a resource as a semantic binding between a URI and a set of representations.
The server cannot "remove all URIs for the resource" unless it has the
ability to determine the semantics of those URI.  In fact, the only ones
it does remove are those that cannot exist without the presence of the
request-URI.

For example, in an Apache negotiation-capable directory, the presence of

    one.txt
    two.txt
    two.htm

also implies the existence of the bindings

    one
    two

If a client were to request a DELETE on "one.txt", then first "one.txt" is
removed (to obey the client request) and the binding for "one" disappears.
If a client were to request a DELETE on "two.txt", then only "two.txt"
is removed.  If a client were to request a DELETE on "one", it should
get a response saying "this is not the source, see one.txt".  Of course,
this is the simplest case -- Apache knows the semantics of these URI
because they share a single handler.

The other thing to keep in mind is that the fact that two URI are
currently mapped to the same representation (file) on the server does
not mean that they are necessarily the same resource.  If I have one
resource for "today's weather in Irvine" and another for "Irvine weather
report for 22 Apr 1999", they will map to the same representation today
and different representations tomorrow.  The resource is the concept being
linked to via hypertext, not the representation of that concept that is
retrieved on a given request.  That is why, in order to author any resource,
the author must first find the specific source resource URI (the URI that
binds to the handler's underlying representation for the target resource).

>What has led us to our proposed definition of DELETE as removing one binding
>is a concern about the versioning spec.  In the context a versioning, it
>would be nice for down-level clients to be able to issue DELETE requests and
>have something reasonable happen.  But in the context of versioning, the
>only thing it makes sense to do is remove a single binding.

The other bindings are to other resources, so this argument doesn't make
much sense.  The problem is that people are confusing resources with
filesystem objects.  If you delete "the current version of X", then X
becomes unavailable within the current version set.  This has no impact
on "X version 1.7", even if they were mapped to the same representation
at the time of the DELETE, if the versioning back-end is designed to
keep deleted versions around (like in CVS's Attic).  For that URI, deleting
the resource is identical to deleting a single binding.

....Roy

Received on Thursday, 22 April 1999 17:36:53 UTC