Which file access is the best : Webdav or FTP? [cl

Question

I have to develop a Java application that has to read some files on the network, edit them and put them back.

The problem is that I always did (over the network) file operations through the FTP protocol. But, I recently heard about Webdav which is HTTP based.

Did anyone notice a difference (in terms of speed) between them ? Which one is the best ? Why did they "invent" Webdav if the FTP is good for that?

Answer 1

WebDAV has the following advantages over FTP:

1. By working via one TCP connection it's easier to configure it to bypass firewalls, NATs and proxies. In FTP the data channel can cause problems with proper NAT setup.

2. Again due to one TCP connection, which can be persistent, WebDAV would be a bit faster than FTP when transferring many small files - no need to make a data connection for each file.

3. GZIP compression is a standard for HTTP but not for FTP (yes, MODE Z is offered in FTP, but it's not defined in any standard).

4. HTTP has wide choice of authentication methods which are not defined in FTP. Eg. NTLM and Kerberos authentication is common in HTTP and in FTP it's hard to get proper support for them unless you write both client and server sides of FTP.

5. WebDAV supports partial transfers and in FTP partial uploads are not possible (ie. you can't overwrite a block in the middle of the file).

There's one more thing to consider (depending on whether you control the server) - SFTP (SSH File Transfer Protocol, not related to FTP in any way). SFTP is more feature-rich than WebDAV and SFTP is a protocol to access remote file systems, while WebDAV was designed with abstraction in mind (WebDAV was for "documents", while SFTP is for files and directories). SFTP has all benefits mentioned above for WebDAV and is more popular among both admins and developers.

Answer 2

Depends on what you want to do. For example, the overhead on FTP for fetching a list of files is 7 bytes (LIST -a), while it's 370 bytes with Webdav (PROPFIND + 207 Multi Status).

For sending some file, the overhead is lower on FTP than on Webdav, and so on.

If you need to send/fetch a lot of small files, FTP will prove faster (using multiple connections for correct pipelining, and per-file TCP connection). If you're sending/receiving big files, it's the same on both technology, the overhead will be negligible.

Please see: http://www.philippheckel.com/files/syncany-heckel-thesis.pdf

Answer 3

Answer for question - Why did they "invent" Webdav

WebDAV stands for Web Distributed Authoring and Versioning.

Internet was just not meant for consumption of resources through urls (Uniform resource locator)

But that is what it became.

Because HTTP had strong semantics for fetching resources (GET) and (HEAD). (POST) provided coverage for number of semantic operations while (DELETE) was shrouded in distrust. HTTP lacked some other qualities like multi-resource operations.

In nutshell, it was read protocol and not write protocol.

You would go round about to make your resources (URLs) available for fetching by uploading it though FTP and many number of mechanisms.

WebDAV was supposed to provide the missing story of internet : Support for authoring resource through the same mechanism HTTP. It extended its semantics, introduced new HTTP VERBS.

It also introduced the mechanism to not only read, write, modify and delete a resource (uris) but also make inquires on the meta properties of the resource and modify it. It is not that you could not do it before but it was done through back door mechanism.

So you see, it brought some of the same mechanisms that you expect on file operations on desktop to internet resources.

Following are some of the analogies:

MKCOL     ----- make collection ----- similar to make folder
PROPGET   ---- get properties (meta?) --- same as get info or extended attributes on mac
PROPPATCH --- modify properties
COPY      ---- cp
MOVE      ---- mv

I hope , I have established some of the noble goals of WebDAV as extension to HTTP to support internet authoring. Not sure if we have achieved it though.

For your question

Your application is a client and will have to make do with what mechanism is available - FTP or WebDAV on the other side. If WebDAV is available great, you can use it. But It will take some time getting used to the semantics. FTP is has limited semantics and excels in simplicity. If you are already using it, don't change it.

Which is faster

That is akin to answering, which is faster HTTP or FTP?

On a sly note, if it was such an issue we wouldn't have been downloading / uploading files via HTTP ;)

Answer 4

Since DAV works over HTTP, you get all the benefits of HTTP that FTP cannot provide.

For example:

strong authentication, encryption, proxy support, and caching.

It is true that you can get some of this through SSH, but the HTTP infrastructure is much more widely deployed than SSH. Further, SSH does not have the wide complement of tools, development libraries, and applications that HTTP does.

DAV transfers (well, HTTP transfers) are also more efficient than FTP. You can pipeline multiple transfers through a single TCP connection, whereas FTP requires a new connection for each file transferred (plus the control connection).

Reference

Answer 5

file modification time:

there seems to be a difference how ftp and webdav deal with file modification time.

It seems there is a 'command' in ftp to preserve that time (several ftp clients and servers claim to do that), whereas webdav, if I remember correctly, can get the file modification date but can not set it on upload.

owncloud client and some propriatary webdav clients seem to have a workaround, but that works only in their software

depending on usage, that is a stong argument in favour of ftp. I don't want my files to have their modification date == upload date. After a later download, I would not be able to tell by date which version of the file I have.

Answer 6

Webdav has advantages over FTP regarding easy passing of firewalls (no separate control/data sockets). Speed should be roughly the same as both protocols transfer the file over a raw tcp socket.