- From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
- Date: Thu, 22 Apr 1999 14:31:42 -0700
- To: "Slein, Judith A" <JSlein@crt.xerox.com>
- cc: "'WebDAV'" <w3c-dist-auth@w3.org>
>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