HTTP vs FTP upload

Question

I am building a large website where members will be allowed to upload content (images, videos) up to 20MB of size (maybe a little less like 15MB, we haven't settled on a final upload limit yet but it will be somewhere between 10-25MB).

My question is, should I go with HTTP or FTP upload in this case. Bear in mind that 80-90% of uploads will be smaller size like cca 1-3MB but from time to time some members will also want to upload large files (10MB+).

Is HTTP uploading reliable enough for such large files or should I go with FTP? Is there a noticeable speed difference between HTTP and FTP while uploading files?

I am asking because I'm using Zend Framework which already has HTTP adapter for file uploads, in case I choose FTP I would have to write my own adapter for it.

Thanks!

Answer 1

HTTP definitely puts less of a burden on your clients. A lot of places have proxies or firewalls that block all FTP traffic (in or out).

Answer 2

I do not wanto to be sarcastic, but File Transfer Protocol must be more reliable on file transfer :)

Answer 3

Resource availability / usage is more of an issue than reliability or speed. Each upload consumes resources - thread / memory / etc - on your web server for the duration of the upload. If content upload traffic is significant for large files it would be better to use FTP simply to free your HTTP server to be more responsive to page requests.

Answer 4

Is HTTP uploading reliable enough for such large files

One major advantage of FTP would be the ability to resume aborted uploads. Most FTP servers and clients support this, though it's not always activated. Whereas with HTTP, it's theoretically possible using special headers, but a normal client (i.e. browser) will not support it.

Another advantage would be bulk uploads: very simple in FTP, not so in HTTP.

But why not simply offer both options? HTTP for those who are behind proxies or won't/can't use an FTP client, and FTP for people who have to do upload many or large uploads over unreliable connections.

Answer 5

The big advantage of HTTP is that it goes over firewalls and it's very easy to encrypt---just use HTTPS on port 437 instead of HTTP on port 80. Both go through proxies and firewalls. And these days it's pretty easy to upload a 20MB files over HTTP using a POST.

The problem with HTTP is that it is not restartable for uploads. If you get 80% of the file sent and then there is a failure, you will need to restart at the beginning. That's why vendors are increasingly using flash-based, java-based or javascript-based uploaders and downloaders. These systems can see how much of the file has been sent, send a MAC to make sure that it has arrived properly, and resend the parts that are missing.

A MAC is more important than you might think. TCP checksums are only 32 bits, so there is a 1-in-4-billion chance of an error not being detected. That potentially happens a lot with today's internet.

Answer 6

FTP will consume less bandwidth than HTTP, since the latter will need to encode(base64) the binary content into plain text thus increase the total transfer size. (by 1/3).

However, bandwidth consumption might not necessarily be the major concern, compare to other factors like usability and security, in which HTTP prevail.

Answer 7

I definitely, opt for the HTTP approach as the rest of the people here. The reason for this is what you've said about most of the files being from one to three megabytes.

The problem is for the "rest", so:

Have you considered allowing users to send larger files through e-mail to a deamon script that gets the emails and uploads the emails to the account associated with the sender? Or there is the solution of the flash uploader, in a facebook-like approach.

Answer 8

HTTP upload can support resume as FTP does. It just requires a server-side script that handles HEAD request and "Content-Range". You can find an applet that supports both HTTP and FTP upload at: http://www.jfileupload.com Add-ons section provides sample script for HTTP upload with PHP, ASP.NET or JSP.