[Cross-posting and setting Followup-To:
news:comp.infosystems.www.misc, for obvious reasons.]
[...]
there remains significant ftp traffic, which despite its
superiority to http as a file transfer facility we probably could
do without: everybody believes http is the bee's knees despite it
having been specified for a different job).
What exactly makes FTP better suited for file transfer than HTTP?
ftp allows mirroring, which is essentially hopeless for all except
the barest of web sites.
FTP offers NLST, while HTTP offers Last-Modified:, and both of
them allow for site-specific requests. So, I'd say, they're
even.
Then, it all depends on the intent of the site maintainers. If
they don't wish their resource to be mirrored, FTP won't be of
any help. And if they wish, HTTP won't be such an obstacle.
FWIW, Git works over HTTP.
ftp doesn't provide the wherewithal for sites to produce silly
distractions, in the way that almost all web sites[*] nowadays do.
I don't understand. Isn't it possible to transfer both Flash
and JavaScript over FTP?
Not a real answer, but: http://mywiki.wooledge.org/FtpMustDie
he makes some good points, but he damns the protocol because it's
old, and because the spec was written at a time when decent standards
for rfc writing hadn't been developed.
For me, the worst feature of FTP is that it specifies three (!)
distinct file transfer modes. And all of them require a
separate data connection, which is difficult to support in
stateful firewalls, and thus NAT's. (Not that I care much about
the latter, for there's IPv6.)
Occasionally, the client in use will insist on using of one of
the passive modes, exactly the one the server fails to support
properly. And if, for some reason, changing the client is not
an option, the user is out of his or her luck.
[...]
--
FSF associate member #7257