Why I don't like WebDAV, part 1

Yesterday and today I spent a lot of time using WebDAV updating one web site, and creating another, both at hosts which use that protocol for accessing file directories on hosted sites. It has taken longer than it should have, possibly caused my Mac OS X 10.4.10 desktop to crash, and ultimately forced me to use both the shell and FTP to get permissions set right and the right files in the right places. It shouldn't be this hard. Part of the blame may lay with Mac OS's native implementation of WebDAV, but I've not seen any implementation that is better on the whole.

WebDAV comes up short, because:

  1. It is not reliable. It frequently leaves files incompletely transferred, gets hung during transfers, gets permissions wrong, or issues false alarms.
  2. It is slow. Annoying slow.
  3. It is incomplete. No surprise, being built on top of HTTP, a protocol never meant for file handling semantics. There's no clean and reliable way to do stat(2) and chmod(2) functions -- something pretty much implemented in every file system used on the server side, and necessary for getting the job done.
  4. There are no industrial-grade or polished, complete implementations. Is there any implementation not based on the Neon libraries? Not to criticize the authors of Neon; after all, it's a volunteer open-source project -- but, Neon has not exactly had a lot of active development and rigorous testing (other than by poor hapless users).
  5. It's obtuse. Did they really have to invent new names for everything?

Some people praise or use WebDAV over FTP, because of FTP's 2 biggest glaring short-comings -- lack of encryption (a solved problem) and lack of authentication flexibility (how hard can it be to add that to an FTP server?). That's hardly a good reason to invent and use a new protocol which fails to meet the needs in a bunch of other ways, and is pig slow and inefficient compared to FTP. Why not just improve FTP?


Re: Why I don't like WebDAV, part 1

You should make a distinction between interface and implementation. The WebDAV protocol is the interface and the implementation can be anything. You can assess the quality of the interface only by studying it. If you want to do a survey on implementations you should test and examine several.

The reliability of a WebDAV exchange depends on both the client and server, where the server has most of the responsibility. Servers can use transactions internally, for example, in order to provide data integrity.

In the WebDAV protocol there are no exchange scenarios known to me that are inheritably slow. With respect to moving files there is not much difference between HTTP and FTP. Both support block-mode streaming. I would say HTTP has an advantage over FTP, because it makes using compression very easy. This dramatically reduces the required bandwidth.

The WebDAV protocol is a much richer interface then any file system can offer. You don't need chmod, because you have ACLs, which are much more powerful (and supported also by quite a few file systems). Searching a WebDAV server is very powerful and potentially much faster, because it is not required to map directly to an underlying file system. You have versioning and very advanced configuration management.

For implementations please refer to http://www.webdav.org/projects/.

Werner Donné.