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

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Oct 2007 18:05:55 +0100

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.

>    2. It is slow. Annoying slow.

No, it's not.

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

>    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

---

From: Mike Douglass <[email-masked]>
Date: Tue, 30 Oct 2007 13:41:11 -0400

These are all implementation issues.

I use subversion every day and it's fast and very reliable - 
surprisingly so for a networked protocol.

I also use a Xythos server when I have the time - it's appallingly slow 
but it's neither Xythos nor the protocol - the server is a slow desktop 
machine

Julian Reschke wrote:
>
> Hi,
>
> the blog <http://tinpixel.com/node/28> requires a login to comment, so 
> I rather just do it here...:
>
>> 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.
>>
>>    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.
>
>>    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).
>
> 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?
>

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

---

From: Jim Luther <[email-masked]>
Date: Tue, 30 Oct 2007 11:06:13 -0700

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

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.

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.

>> pretty much implemented in every file system used on the server  
>> side, and necessary for getting the job done.
>

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.

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

---

From: Joe Orton <[email-masked]>
Date: Wed, 31 Oct 2007 14:04:15 +0000

> something that already is on the web.

DAV is typically (really, always) *faster* than FTP, since it doesn't 
require the set up of a new TCP connection for each data transfer.  

Understanding the impact of separate DTP/control sockets answers the 
"Why not just improve FTP?" question for most people, I'd suspect.

joe