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