CommunityWiki: Web Dav Vs Ftp

On InterwikiDiscuss, Dennis Hamilton pointed out that WebDav's primary UseCase (updating collections of documents on the web) can also be accomplished using tried-and-true FTP. Given a more entrenched standard, what's the point of using WebDav?

First, the official answer, on the offical WebDav site, from Greg Stein.

A list of reasons to use WebDav:

Even if FTP can handle this one use case pretty well, WebDav can potentially fill many more kinds of roles, too1.
WebDav does locking and "properties" MetaData 2.
TheWebIsTheUltimateNameSpace? argument.
- it's a pain to have all these different protocols with all of their different addressing schemes. While the internet already provides "the ultimate name space" in terms of providing an IP address for each computer, we also need finer-grained addresses with which to identify individual documents and individual applications. Web servers provide the most canonical way to give addresses to individual locations within the filesystem of a server. With CGI, these addresses can be used not just to identify documents, but also to ask for particular servers to be spawned (WebServices).
- Since TheWebIsTheUltimateNameSpace?, we want to replace non-HTTP-based protocols with HTTP-based protocols whenever possible so that we don't have to worry about multiple name spaces (for example, if I want to edit web page A via FTP, then I need to map the URL of A into a path to give to the FTP server).
FTP is more complex than WebDav for a client to implement 3
FTP sessions are stateful, WebDav is not 4
WebDav has more support for versioning (see also DeltaV)
FTP is insecure (it sends passwords in the clear). (However, this doesn't explain why WebDav is better than SFTP)
If you do everything over HTTP, that's one less port that you have to open, security-wise5.
You can use MIME types6.
WebDav is new, FTP is old
With WebDav, you can edit "locally on the client"?!? 7
With WebDav, you get to use stuff built into HTTP for free (encryption, proxies, certificates, caching, etc).
WebDav is specifically designed to make it easy for a group of people to collaboratively edit their website.

Discussion

BayleShanks

I have to say, most of the particular little reasons don't sway me much… I'm almost inclined to stick with FTP. However, these three reasons do the most towards convincing me that WebDav might be better:

(appeal to authority). WebDav is new, FTP is old. Lots of people have implemented FTP-like interfaces for WebDav. Therefore, the WebDav guys are totally aware that they are competing with FTP. If they didn't think they had something much better, they would have stopped making it. I can rely on them to do my thinking for me.
WebDav can potentially fill many more kinds of roles than just FTP. If one protocol really could do file transfer, web administration, email, and CVS, that would be very elegant.
The potential of versioning. Since the application I have in mind is wikis, this is crucial.

AlexSchroeder

Here's how I see it:

It seems WebDAV is easier to implement ("FTP is more complex than WebDav for a client to implement" and "FTP sessions are stateful, WebDav is not")
Potential for versioning. This is actually the reason I will abandon my implementation using a virtual filesystem layer. That will preclude access to versioning.

Adressing and ports closed by firewalls should be no problem because you can use FTP URLs for many clients such as the Windows Explorer.

As for editing locally – I think this may already work with some FTP implementations such as the support built into Windows. I'm not sure, though.

My wiki does not require locking, and I think what they call "specifically designed to make it easy for a group of people to collaboratively edit" is just that: Locking support.

I'm not too concerned with mapping HTTP URL to FTP URL because my usecase involves people using either only FTP or only the Web, not interleaving both.

MarioSalzer: WebDavs negliance is well deserved. A couple of misdecisions in the specification (authentication required) and technical shortcomings (e.g. the XML namespace glitch) but also its overall complexity made it the eschewed protocol it is today, and I don't think it is worth the time for Wikis to support it (- I in fact did implement it partially, so allow myself to comment here).

FTP (not really "more difficult") obviously can hardly be compared with anything HTTP-based, even if most clients today use HTTP also only as pure file transfer scheme. Therefore WebDav would of course be the superiour of the two, if it wasn't that current clients (which won't go away anytime soon) aren't all too HTTP-compliant either.

What especially catched my attention and what I'd like to dissent in the above list was "You can use MIME Types". Most clients (and sometimes even servers) just send "application/octet-stream" because everybody is in the wrong belief that this was 'more reliable' or so. And here I personally think, if implementations can't even get the most basic HTTP meta information right, it's not worth to talk about any other WebDav features.

HTTP/WebDAV SEARCH or DeltaV may be interesting technologies, but its deeply nested XML is overkill (meta data needs just a hash/dictionary) for most of its tasks and therefore left us with lots of half-finished applications. My hope is that something better gets out of the Atom WG.

AlexSchroeder

Where in the RFC does it say that authentication is required? I've heard that claim before but cannot find any evidence for it. What about the XML namespace glitch. Can I read this up somewhere? Which part did you feel to be needlessly complex, and what are you comparing it to? To discard WebDAV as a protocol because most clients don't treat MIME types correctly seems to defy sound reasoning. There seems to be a lot of frustration here – but without the necessary background it is hard to understand your message.

MarioSalzer: That's exactly the point. The RFC never said that authentication was required, it however pledged too lengthy for strong authentication (SSL or Digest instead of Basic auth) and the text therefore became unclear enough to make implementors think it was required. (It's however not too farfetched to assume that the original WG never thought about freely writable resources or Wikis at that time.)

The "XML namespace glitch" simply refers to the xmlns:ns0="DAV:" URI, which strictly speaking is not a valid URI and should therefore lead to immediate XML parser errors. To our luck most parsers ignore this. (The problem here was probably, that the WebDav spec was finished before XMLNS.)

What I said about the MIME types is just, that WebDav has little advantage over FTP on this point. For a HTTP-based protocol this is a real drawback. Ignoring or sending false MIME types is inacceptable (it's the Microsoft way). The client I last toyed with was Konqueror, and if even such a respected tool doesn't get it right, I think it's indeed time for a little bit frustration

Everybody could extend an FTP server and add new functions like GETMETA or LOCK easily, it could even be made to serve dynamic content. WebDav on the other hand provides most of those features already, but apart from FTPs two ports is not really easier to implement (I don't understand that sentiment at least). The meta data you can transfer over WebDav can be arbitrarily rich, but is unlikely to get preserved or honored at the other end of the wire, because XML rarely maps to native data structures or content databases or gets kept as-is. (I'm still the opinion, something like "multipart/mixed" would have sufficed for directory listings.) That's why I think there's too much additional work with WebDAV.

For the comparison of pure file transfer mechanisms, therefore, I conclude WebDAV is not in advantage over FTP. WebDAV brings and allows lots of other gimmicks (I was recently trying to bind a WebDAV server to OpenID authentication for example) and as a HTTP-based scheme looks much cleaner, but still: could have been better.

WebDavVsFtp

Discussion

Footnotes: