Re: Some problems with the WebDAV protocol

> > 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.
> 
> Actually, they are compatible with the HTTP/1.1 spec.

HTTP/1.1 says: "applications MUST understand the class of any status
code, as indicated by the first digit, and treat any unrecognized response
as being equivalent to the x00 status code of that class". So an HTTP/1.1
client must interpret a 207 as being the same as a 200, although it clearly
has a totally different meaning in WebDAV. It seems to me that a server
which provides an error response (to an HTTP/1.1 request) as a 207 is not
acting in an HTTP/1.1 compliant manner. 

> > 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).
> 
> That's a feature.

It would be a legitimate feature if WebDAV was only introducing new
methods. In such case the request itself, which uses a new method,
indicates to the server the use of the new protocol. But if given
methods have different semantics in the two protocols, then what
kind of a "feature" is that? I call it a bug.

> > 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).
> 
> That's a matter of opinion; I say it should be possible to delete a collection and
> know that clients that don't MKCOL it won't recreate it.  The fact is that, as you
> admit, the HTTP/1.1 spec does not forbid the behavior which DAV prescribes.

Nor does HTTP/1.1 forbids to disallow PUT altogether, or to disallow
resource names to have more than 5 characters, or...  The point is that
it does allow functionality that WebDAV forbids, and this functionality
is being used (so it's not a purely theoretical matter).

> > 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.
> 
> So don't make it DAV compliant on the whole server; leave it alone in trees where
> people are using PUT.

Why? These "trees where people are using PUT" are their web sites. It is
exactly where one wants to add WebDAV support, in order to add more
functionality to what PUT and DELETE currently allow. Not in order to break
the existing functionality. What I'll do is implement WebDAV without obeying
this restriction, because it is very unlikely to cause any problem anyway.
But what's the point of having a protocol restriction that does nothing
useful and encourages people to be non-compliant?
 
> > 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?
> 
> Consistency.

With what? Why is it important or beneficial in any way?

> > 2) WebDAV can introduce new methods to implement its favorable PUT and DELETE
> 
> Ugh.  Adding DAV to a server should automatically include the DAV-like functionality
> of base HTTP/1.1; there shouldn't be two ways of doing the same thing.

Using DAV-like functionality of base HTTP/1.1 is one thing. Redefining that
functionality is another.

> > Another (not related) problem with the current protocol is the requirement
> > that servers must respect PROPFIND with Depth=infinity queries for collections.
> 
> Access control.

And this helps how? By making public content repositories outside the scope
of WebDAV? Or maybe anything as large as the Linux kernel source tree is
outside its scope? (5000 files should yield MegaBytes of XML.) Or maybe
clients can be counted on to always know in advance the size of collections,
so they will never issue Depth=infinity requests to large ones?


Yoram Last

Received on Sunday, 18 April 1999 17:41:17 UTC