HTTP vs FTP upload

The big advantage of HTTP is that it goes over firewalls and it's very easy to encrypt---just use HTTPS on port 443 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/HTTPS 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.

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.

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