An anonymous coward asks "Looking to serve files for downloading (typically 1MB-6MB), I'm confused about whether I should provide an FTP server instead of / as well as HTTP. According to a rapid Google search, the experts say 1) HTTP is slower and less reliable than FTP and 2) HTTP is amateur and will make you look a wimp. But a) FTP is full of security holes. and b) FTP is a crumbling legacy protocol and will make you look a dinosaur. Surely some contradiction... Should I make the effort to implement FTP or take desperate steps to avoid it?"
Not often I post to the list, but what the heck?
FTP vs. HTTP is your classic "Horses for courses" discussion - one is better than t'other for some situations, and not as good for others.
For example, HTTP is great if: 1. You want to let people download single files via hyperlinks on a Web page. An HTTP link is just a link to a file, which when clicked will make the browser download it.
2. You want the client browser to open the file (e.g. a PDF or Word doc) either via a plug-in or an external application. HTTP stamps each file (or each section within a multipart download) with a MIME type, which the browser can use intelligently. So if my Internet Explorer or Netscape spots that it's a PDF document from the MIME type, it launches the Adobe Acrobat Reader plug-in. If it sees a Bloggit document and doesn't have a Bloggit plug-in, it simply launches the application under Windows and passes the filename to it for opening. This is much harder to do with FTP - it basically depends on the client machine being able to use the file extension (e.g. .PDF, .DOC) to map it to an application.
3. You have a Web server and you don't want to muck about setting up FTP. Many machines come with HTTP set up out of the box but not FTP. And if you want to set up anonymous FTP you have to be dead careful you don't open all manner of security holes.
4. People using your site have firewalls that have a hard time with FTP connections. Most of us understand that sometimes you have to switch your FTP client to Passive mode if you're behind a firewall, but many people I speak to (i.e. who say "I can't FTP this file") don't realise this, which can be a pain.
FTP is great if: 1. You want to download multiple files. There's nothing quite like an "mget *" to make life easy when you're downloading (say) the 15 patches for your kernel that have come out since you last patched it.
2. You want to allow people to upload files. You can use HTTP's PUT command, but it's nothing like as easy to work with as an FTP PUT.
3. You want to enforce access control depending on user ID & password. Although you can do access control with an HTTP server, it's far from elegant in most cases, particularly if you want it to integrate with the user database (or global directory service) on the server computer. FTP servers, on the other hand, tend to be easier to fly in this respect, and generally integrate much more tightly to the OS's user database than would be the case with an HTTP server. I'm not saying you can't do it with HTTP, just that it's not as elegant in the average case.
4. Your clients have intelligent FTP clients. Ever tried FTPing from (say) a Red Hat 7.2 box to another Red Hat 7.2 box? Do an "mget *" and the server will tar and gzip all the files into a single compressed archive, then send over that single archive; the FTP client will unbundle everything and leave you with a file structure like the one it started with at the other end, but with a far more efficient transfer in the middle than would have been the case with numerous files (particularly if the files were small).
At the end of the day, there's not a lot you can' t do with FTP that you can't emulate with HTTP, and vice versa. For most of what we all do, I suspect that HTTP will outnumber FTP in the majority of cases, because we don't do anything particularly complex in most of our sites. The only situation where I use FTP on my servers, for instance, is where people rent space on my server for their home pages, and they use FTP to upload the pages. Everywhere else I use HTTP, mainly because MIME typing lets the client browser be clever about what it does with documents.
D.