- From: Roy T. Fielding <fielding@apache.org>
- Date: Fri, 7 Mar 2003 16:26:49 -0800
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "Brian Korver" <briank@xythos.com>, "WebDAV" <w3c-dist-auth@w3.org>
> The URL is an identifier for the resource, which allows the client to > interact with the resource (in HTTP mainly by retrieving and > manipulating > representations of these resources). WebDAV has added collections and > properties, but these do not really change the underlying model. > > When I submit a request to an HTTP server, it uses the request URL to > locate > an internal resource object. HTTP allows multiple URLs for the same > resource. Once the object was located, the name (the request URL) > becomes > irrelevant -- the results of the interaction should be independant of > the > way the server located the resource. It uses the request URI to locate an implementation object. Neither is the HTTP resource. The name is always relevant in this process, even after the implementation object is found, because the implementation will use the name to determine which representation should be returned in response to a GET. Each representation has its own set of properties. It is therefore false to say that two bindings to the same WebDAV resource will have the same properties because WebDAV defines the resource to be the implementation object (unlike HTTP). WebDAV doesn't understand server-side content negotiation because it doesn't deal with negotiated URIs. The bindings spec has no choice but to understand it, since that is the primary reason to have bindings (as opposed to redirects). In order to make sense of bindings it is necessary to return to the proper definition of resource and representations, wherein it never makes sense to say that the binding attaches to a resource, because the binding is part of what defines the HTTP resource (the mapping function). > Using my favorite analogy (the Unix filesystem :-) The Web is not a distributed filesystem. Resources are not files. Why use broken analogies to explain a process which is self-evident in almost all general-purpose HTTP origin servers? Just use what has already been implemented. ....Roy
Received on Friday, 7 March 2003 19:25:21 UTC