86

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?

Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197
David
  • 869
  • 1
  • 6
  • 3
  • 6
    I wonder if this question could be reworded to merit reopening. At first glance, FTP and WebDav seem to serve exactly the same purpose, and it would be very helpful to know when to use one over the other. – Ajedi32 Jan 28 '15 at 19:55
  • 15
    Related: [Can questions that ask for a comparison be constructive?](http://meta.stackoverflow.com/q/251328/1157054) According to that, this question is unsalvageable. On the other hand, this question currently has almost 30k views, and numerous upvotes, and despite the assertion in the close reason that "answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise", the answers to this question clearly demonstrate otherwise. – Ajedi32 Jan 28 '15 at 20:07

6 Answers6

90

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.

user7610
  • 25,267
  • 15
  • 124
  • 150
Eugene Mayevski 'Callback
  • 45,135
  • 8
  • 71
  • 121
  • Partial uploads are not defined in any standard. – Evert Sep 14 '13 at 15:29
  • @Evert what *any* did you mean? Nobody forbids Range and Content-Range in HTTP so when both client and server can handle it, it's possible. – Eugene Mayevski 'Callback Sep 14 '13 at 19:09
  • 3
    Those headers are specifically for _fetching_, not uploading resources. The httpbis specs specifically recommends against using ranges in combination with PUT requests as it can lead to undesired results. Source: I'm the author of a major webdav server and I plow through rfc's on a daily basis. – Evert Sep 14 '13 at 19:37
  • 1
    @Evert (1) "headers are for fetching" - do you have a normative reference? (2) The fact that some draft discourages something doesn't mean that's forbidden. We also develop and sell WebDAV components :-P – Eugene Mayevski 'Callback Sep 15 '13 at 06:11
  • Read: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-5.3.4 Treat it as 'some draft' if you want, but this document also specifies the reasoning for discouraging ranges for PUT. An argument which is quite valid. – Evert Sep 15 '13 at 12:42
  • So unless you have a proprietary discovery mechanism for ranged PUT requests, there's no way for a http client to know beforehand whether the range headers will be ignored or not. If they are ignored, the end result is something entirely different from the expectation. – Evert Sep 15 '13 at 12:45
  • 1
    @Evert It's just the server that must report that it doesn't support range requests, when it receives one. Nothing more than a bit of care from server developer ;). – Eugene Mayevski 'Callback Sep 15 '13 at 14:37
  • And you've given a link to the expired work-in-progress document (I understand there can be later versions). Whatever "reasonable" it is, it's just a work in progress. Once it's approved, we'll reconsider our position, and until then the valid RFC allows use of ranges. – Eugene Mayevski 'Callback Sep 15 '13 at 14:38
  • 2
    Fair enough. Just remember that that paragraph was added because of real world problems, not because they felt they wanted to be more restrictive. – Evert Sep 15 '13 at 15:06
  • sftp doesn't support remote copy, compression, searching, etag(!), notification, wide OS support or popular extensions. That leads me to think that webdav is still more interesting than SFTP. – elmarco Dec 13 '13 at 11:09
  • 1
    @elmarco you seem to be confusing file access (that the question is about) with remote document management. We are talking about *file* access here. As for "Wide OS support" - that's nonsense as both clients and servers for SFTP exist for all modern platforms from Unix to Windows to Java to Android and iOS (yes, servers exist there). – Eugene Mayevski 'Callback Dec 13 '13 at 13:06
  • @EugeneMayevski'EldoSCorp I am comparing two filesystem protocols with similar fonctionality (I don't get your distinction). When I said "wide OS" I meant native out of the box support (for example, be able to mount the remote filesystem in explorer/finder/nautilus..). – elmarco Dec 13 '13 at 17:04
  • @elmarco WebDAV is NOT a filesystem protocol. I don't know what you are comparing. Neither there's built-in WebDAV server in any desktop or mobile OS. – Eugene Mayevski 'Callback Dec 13 '13 at 17:41
  • 1
    @EugeneMayevski'EldoSCorp apple and oranges; I obviously meant OS client integration support: "be able to mount the remote filesystem in explorer/finder/nautilus" – elmarco Dec 13 '13 at 20:49
  • `It's just the server that must report that it doesn't support range requests, when it receives one.` That blows the principles of HTTP extensibility out of the water. When deploying an HTTP applications for wide use, you should observe the principles of extensibility, which requires that you define custom headers in such way that parties that are not aware of the custom extension should be able to ignore it to no ill effect. This is one of the most important principle for interoperability. – Lie Ryan Jan 24 '15 at 08:04
  • 1
    @EugeneMayevski'EldoSCorp "SFTP is more feature-rich than WebDAV" Would be great if you could elaborate or link. "SFTP is a protocol to access remote file systems.." objectively, what is the significance of this distinction? – spinkus Jun 03 '16 at 12:12
  • It says here, that FTP is faster when transferring many small files https://stackoverflow.com/a/14323701/ – Alex78191 Oct 28 '20 at 20:08
36

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

pyfunc
  • 65,343
  • 15
  • 148
  • 136
6

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

Durai Amuthan.H
  • 31,670
  • 10
  • 160
  • 241
4

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

xryl669
  • 3,376
  • 24
  • 47
  • Nice detail and numbers – Jonathan Sep 22 '14 at 14:50
  • So you're saying FTP is better in all cases. – Milind R Jan 20 '15 at 07:23
  • I'm saying that if you intend is (only) to send and receive files, then FTP is better than Webdav. However, Webdav has numerous other features (locking, sharing for example) not found in FTP. If you deal with big files, then the overhead of webdav is negligible compared to the additional features. – xryl669 Jan 20 '15 at 18:08
  • 2
    WebDAV may use fewer bytes, but ftp needs more connections. If latency is low, and packets are small, ftp may be faster, but over most of the modern internet bandwidth is considerable, while latency isn't necessarily great - and here, (pipelined) WebDAV is likely to outperform FTP. – Eamon Nerbonne Sep 17 '15 at 15:13
  • 2
    With encryption, behind firewalls and NAT, the chances of WebDAV functioning is much higher than FTP(S), due to content rewriting and sniffing needed to make FTP work... – Gert van den Berg Jun 29 '17 at 08:58
  • That's true. If you're local (which the OP seems to imply) and only care about transferring files, FTP might still be better. – xryl669 Feb 23 '18 at 21:24
  • I wonder why nobody mentioned the real overhead: The webservers latency. I mean you need Apache 2 and PHP to run a WebDAV server like SabreDAV, while an FTP server like vsftpd uses machine code. – mgutt Nov 07 '19 at 11:30
2

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.

Jan-Philipp Niewerth
  • 151
  • 3
2

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.

opto
  • 57
  • 6