- From: Yoram Last <ylast@mindless.com>
- Date: Sun, 18 Apr 1999 03:28:57 +0300
- To: w3c-dist-auth@w3.org
I would like to point out some problematic aspects of the WebDAV protocol as it is formulated in RFC 2518. The main problem I would like to address involves the PUT and DELETE methods. These methods are defined in HTTP/1.1 (RFC 2068) and are currently fairly widely implemented and used (although PUT is probably more widely used than DELETE). The problem is: 1) WebDAV redefines these methods in a way which is essentially incompatible with HTTP/1.1. Thus putting itself in conflict with HTTP/1.1. 2) WebDAV does not seem to provide a way for servers to differentiate WebDAV clients from other HTTP/1.1 clients (at least not in the context of clients using these request methods). This seems to create a problematic situation in which adding WebDAV compliance to a server necessarily involves breaking some (potentially important) HTTP/1.1 compliant functionality as well as compliance with the HTTP/1.1 protocol itself. IMHO, this is unacceptable. The more concrete aspects of this problem are as follows: 1) RFC 2068 says about PUT: "If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI." There is nothing in RFC 2068 forbidding the creation of additional resources in this process or otherwise restricting the server in what it may or may not do in order to create the resource with the appropriate URI. While HTTP/1.1 has no explicit notion of collections, implementations of it certainly do (typically, servers match URI's to an hierarchical file system or something equivalent), and in most cases a PUT request into a collection (directory) that does not exist can only succeed by the creation of one or more intermediate collections. While a server may clearly forbid such PUT operations (it may impose whatever restrictions it wants on its name space), a friendly PUT implementation (which tries to maximize its functionality) should transparently create missing collections (since HTTP/1.1 has no MKCOL method or an equivalent). Since the most popular method for implementing 'PUT' is "write your own script" (see http://www.apacheweek.com/features/put), it is hard to say how many servers actually allow transparent creation of missing collections using PUT. However, there are certainly some servers that do that (concrete examples include Jigsaw, the W3C's testbed server, available from http://www.w3c.org/Jigsaw/, and Lyonel Vincent's 'mod_put' for Apache, available from http://hpwww.ec-lyon.fr/~vincent/apache/mod_put.html), and this allows many existing clients (Amaya, Netscape composer, AOLpress, etc., non of which knows anything about MKCOL) to create collections by PUTing files to appropriate URI's. RFC 2518, on the other hand, explicitly says: "When the PUT operation creates a new non-collection resource all ancestors MUST already exist. If all ancestors do not exist, the method MUST fail with a 409 (Conflict) status code." So, if I have a server on which people can now create collections by using existing HTTP/1.1 compliant clients (namely, with PUT), and I will go and make it strictly WebDAV compliant, this important functionality will be broken. This is a problem. 2) The main problem with DELETE doesn't so much effect functionality as it effects compliance with HTTP/1.1 and has the potential of confusing HTTP/1.1 compliant clients. In connection with DELETE for collections, RFC 2518 says: "If an error occurs with a resource other than the resource identified in the Request-URI then the response MUST be a 207 (Multi-Status)." Since 207 is not a valid HTTP/1.1 response, HTTP/1.1 clients are not supposed to be able to understand it. They are likely to consider it as a success code (it's a 2xx) even though in this particular case it actually indicates failure. So how can these issues be resolved? There seem to be at least three basic ways: 1) WebDAV can withdraw from redefining existing HTTP/1.1 methods, and reassign to these methods their original HTTP/1.1 requirements without new restrictions and without allowing the use of status codes that do not exist in HTTP/1.1. The restriction on PUT seems totally artificial anyway. A server that has a problem to create missing collections is always allowed to forbid it. But what is the point in forbidding all servers from doing that? If one wants to encourage clients to implement and use MKCOL, it is enough to make it a requirement on the client, while permitting the server to maintain its support for legacy clients. The DELETE issue is a bit more complicated, since some functionality is clearly lost if one is restricted to HTTP/1.1 responses. Note that nothing prevents an XML response from still being sent, except that WebDAV seems to tie the interpretation of such responses to a 207 code. In any event, it would be better than breaking HTTP/1.1. 2) WebDAV can introduce new methods to implement its favorable PUT and DELETE variants, while leaving PUT and DELETE (untouched) in the realm of HTTP/1.1. It is interesting to note that Netscape's "DISTRIBUTED AUTHORING AND VERSIONING PROTOCOL" (which is implemented by their Enterprise server) defines its own EDIT, SAVE, and DESTROY methods which are very similar to the normal HTTP/1.1 GET, PUT, and DELETE methods. By implementing new methods, they become free to define the behavior, headers, etc., of these methods as they wish, without running into a conflict with any existing protocol. WebDAV can also adopt this approach. 3) WebDAV can implement a way for both clients and servers to identify themselves as WebDAV compliant, and make the implementation details of existing HTTP/1.1 methods dependent on this identification. I think that a reasonable way of doing that can be to use the already defined DAV header. Instead of just sending this header in response to OPTIONS requests, it can be made an integral part of any request-response cycle. Namely, a client should be required to supply it in every request, and a server should supply it in any response (to such a request) involving a WebDAV compliant resource. The DAV header can then be used and understood in a similar way to the protocol (HTTP/1.x) designation in HTTP exchanges. That is, indicating to both sides the capabilities of the other one. Furthermore, the DAV header in a request would be interpreted as requesting the server to comply with the WebDAV protocol, leaving the server free to behave otherwise in response to requests that do not contain this header. In particular, PUT and DELETE without a DAV header would be interpreted as HTTP/1.1 requests coming from HTTP/1.1 clients, and other methods need not even be defined. Note that this mechanism can have further usage. In particular, the behavior of other existing HTTP/1.x methods can be legitimately modified, and future WebDAV development may use it to fine-tune responses and/or to change the semantics of current methods (in the context of new compliance classes) while maintaining backward compatibility. Out of these three, I tend to vote for number 3. In any event, one way or the other, I think the current situation needs to be fixed. Another (not related) problem with the current protocol is the requirement that servers must respect PROPFIND with Depth=infinity queries for collections. Consider a site like ftp.cdrom.com, and suppose they would want to enable WebDAV-based access to their site (say, in order to enable people to browse their site with the new Microsoft web folders feature). The size of the ls-lR file for their site is around 75 MB (yes MegaBytes) and the size of a proper response to a PROPFIND with Depth=infinity to it would probably be at least 500 MB. It would take at least two days to transmit over a dial-up connection, and would probably require a super computer to parse it. Do you seriously think they should (or would) supply such responses? The protocol can say what it will, but it is totally crazy to think that servers would universally implement something like this. The current requirement in the protocol may lead to naive client implementations that would rely on getting info on the entire tree in a single request, even though not all servers would allow it. I propose making it legitimate for the server to respond to PROPFIND requests with Depth=infinity with a Depth=1 response. In order to prevent confusion, the Depth header can be included in responses as well as in requests. That is, if a server gets a PROPFIND request with any given Depth, it may choose to respond to a lower Depth, and in such case it MUST supply a suitable Depth header in the response which indicates the actual Depth to which the response corresponds. Absence of a Depth header in the response would indicate that it corresponds to the requested Depth. Sounds reasonable? Sincerely, Yoram Last
Received on Saturday, 17 April 1999 20:29:21 UTC