|
Jorey Bump
list at joreybump.com
Fri Mar 25 16:04:43 EST 2005
Jamie Becker wrote: > Since people download ISO's via HTTP all the time, it's best to err in > the realm of possibility where possible and assume that sometimes they'd > upload ISO's via HTTP as well. (http://www.linuxiso.org, for example.) > HTTP has some unique flexibility and security advantages, especially > over FTP. Not that I recommend large files over HTTP either, but there > are circumstances where I can see that functionality being useful and > within the realm of good design. I routinely perform DoS attacks on my home network, usually whenever there is a new Knoppix or Slackware release. :) Even with DSL, the effect on my throughput can be severe enough that I usually run these tasks overnight. The mirrors I use are meant to support a one-to-many relationship, but some of them are under a strain simply returning such large files and there is a limit to how many simultaneous connections they can support. Can you imagine if the situation was reversed, and everyone was *uploading* an ISO? Clearly there is a difference, which you can simulate somewhat by trying to download several ISOs to one machine. You're right that uploading files via a browser is useful, and I incorporate it regularly in applications for nontechnical users, but I can't think of a single server I admin on which I would consider using HTTP for ISO uploads. This implies a technical use that is appropriate for FTP, or rsync or compressed scp/sftp if the users have shell accounts. > Another example is uploading a zipped-up directory of photographs for a > photo gallery, rather than go through an individual file upload for each > one. HTTP can be very good at these sorts of things, while FTP can be > hazardous at best. Many transfer protocols are optimized for improved bandwidth usage and data integrity, both areas that aren't as well supported in HTTP uploads (will your browser automatically gzip your ISO or report server-side errors?). The main problem with FTP is that it's a multiport protocol, which is out-of-place in today's firewalled world. It's still better than HTTP because it provides better feedback about the destination and supports many more commands. Security concerns can be minimized by chrooting users to home directories. But, yes, FTP generally sucks and sftp gives away the store by requiring a shell account. WebDAV is still immature and requires many layers of administration. It will be nice when someone develops a simple, secure transfer protocol that isn't attacked by the RIAA or used as a virus distribution mechanism.
|