Re: Blog comments on <http://tinpixel.com/node/28> -- "Why I don't like WebDAV, part 1"

I guess I'll throw in my 2 cents. I don't work on Mac OX X's WebDAV  
file system now, but I used to.

On Oct 30, 2007, at 10:05 AM, Julian Reschke wrote:

> Hi,
>
> the blog <http://tinpixel.com/node/28> requires a login to comment,  
> so I rather just do it here...:
>
>> Why I don't like WebDAV, part 1
>> Posted October 23rd, 2007 by chris
>> in
>>    * gripes
>>    * protocols
>>    * software
>>    * technology
>>    * webdav
>> 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.
>
> That's an implementation problem. I'm not sure what server was  
> involved, but this has nothing to do with the protocol itself.

Apple's WebDAV file system works with most WebDAV servers that act  
like file servers, but there's nothing in the WebDAV spec that says a  
WebDAV server has to act like a file server just as there's nothing in  
the HTTP spec that requires an HTTP server to only serve up resources  
a web browser can us). There are many WebDAV servers that don't act  
anything like a file servers, and others with restrictions that ensure  
they cannot be used as a general purpose file server (like the  
filename restrictions imposed by MS SharePoint servers).

IMO, Apple's WebDAV file system should have been called the "iDisk  
file system" to make it clear what server it was intended to work with  
and if it happened to work with other WebDAV servers (such as Apache  
mod_dav servers because they act like file servers)... great; if they  
don't work with other WebDAV servers... oh well.

>>   2. It is slow. Annoying slow.
>
> No, it's not.

With a fast server, I haven't seen that the WebDAV file system is  
slow. If the server responds slowly to requests (I've seen some WebDAV  
servers take as much as 1/2 second to respond to PROPFIND requests --  
that makes the handling of stat(2) requests rather slow and you'd be  
amazed how often programs call stat(2)) or you're using a high latency  
connection, things will be 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.
>
> I don't see why PROPFIND wouldn't be sufficient for stat(2), and ACL  
> (RFC3744) wouldn't be sufficient for chmod(2).

The WebDAV file system was meant to copy files up to a server or down  
from a server. It wasn't intended to conform to the POSIX spec.

As Julian pointed out, support for ACL (RFC3744) would allow chmod(2)  
like behavior, but at the expense of additional transactions with the  
server (which will affect performance). Since it wasn't important on  
iDisk, it wasn't added.

>>   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).
>
> Subversion seems to be quite happy with Neon. That being said,  
> there's also serf (<http://code.google.com/p/serf/>) or the Apache  
> httpclient libs.
>
>>   5. It's obtuse. Did they really have to invent new names for  
>> everything?
>
> I'm not sure what this is about... Maybe the author would have  
> preferred "STAT" over "PROPFIND"?
>
>> 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?
>
> WebDAV is as fast as FTP, usually being only limited by bandwidth  
> and latency of the link. And of course there are lots of other  
> reasons to like WebDAV, such as that it *is* HTTP -- no new URI  
> needed to edit something that already is on the web.
>
> Best regards, Julian

A few other reasons to prefer WebDAV/HTTP over FTP:

* HTTP authentication support is much better than FTP

* HTTP works through proxies much better than FTP

* Parsing the response from PROPFIND is MUCH, MUCH easier than writing  
a parser that can parse the multitude of results you get back from  
FTP's LIST command (as rfc0959 says, "Since the information on a file  
may vary widely from system to system, this information may be hard to  
use automatically in a program, but may be quite useful to a human  
user.")

Received on Wednesday, 31 October 2007 00:41:52 UTC