Some problems with the WebDAV protocol

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