Re: Some problems with the WebDAV protocol

Yoram Last wrote:

> 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.

> 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.

> 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.

> 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.

> 2) The main problem with DELETE doesn't so much effect functionality as

You mean "affect".

> 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.

Does it? Some parts have succeeded, others have failed; which is it?

Besides, remember that RFC-2068 does *not* require that DELETE actually delete
anything:

     9.7 DELETE

     The DELETE method requests that the origin server delete the resource
     identified by the Request-URI. This method MAY be overridden by human
     intervention (or other means) on the origin server. The client cannot be
     guaranteed that the operation has been carried out, even if the status
     code returned from the origin server indicates that the action has been
     completed successfully.

> 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.

> 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.

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

Access control.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
|francis@ecal.com|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

Received on Saturday, 17 April 1999 22:02:38 UTC