It was thus said that the Great der Mouse once stated:
Nothing strange about it; this is really the only sensible thing to do
when you want to be able to abort a transfer cleanly (something HTTP
doesn't bother to even try to do).
Well, HTTP was a later design than FTP, and initially, was a simpler
protocol than FTP [1] and the assumption was that initiating TCP connections
was "cheap" and that if you wanted to abort a connection, you'd drop your
side of the connection.
HTTP also offers nothing like REST or the various
other filesystem
manipulation commands like ACCT, CWD, CDUP, SMNT, STOU, APPE, RNFR,
RNTO, DELE, RMD, MKD, PWD, LIST, NLST...indeed HTTP doesn't really
offer file transfer at all - it's just common for a request to be
satisfied by serving up a copy of a file, and this is (ab)used as a
file-transfer mechanism.
HTTP/1.1 (the current version) allows one to restart a file download, and
now even allows one to create a file (via PUT), copy (COPY), delete (DELETE)
and move (MOVE) resources. Well, files, but since HTTP works with URLs
there doesn't have to exist a one-to-one match between a request and a file
[2].
http does the
same, but you can use https (http with SSL/TLS
encryption). There is a SSL variant of ftp, but I know of no client
or server that supports it.
I can only assume you haven't bothered to look. One googling (FTP SSL
client) turned up what looks lke a whole bunch of them; I followed the
first of the returned link and the page I found claims at least 40
client and 28 server implementations that support AUTH (which doesn't
necessarily mean SSL, but does mean something better than cleartext
reusable passwords). It also lists 45 FTP clients that (it says)
support one of the three forms of SSL-secured FTP it outlines, so
presumably the counts are out of date.
Wow, that's new to me, and I've been using the Internet since 1989.
-spc (Looked through the FTP RFC, extensively read the HTTP RFC and have
helped write a webserver ... )
[1] The original version, 0.9, was:
connect to the specified port
GET path\r\n
And start receiving the data. Yes, it was *that* simple. It's been
built on ever since.
[2] For instance, there doesn't exist a single "file" for the request
http://boston.conman.org/2000/8/11-15
which describes a vacation I took through northern Florida a few
years ago. Not even
http://boston.conman.org/2003/7/4
describes a single "file", but conceivably I could apply a DELETE on
said URLs, or even a MOVE or COPY. Even a PUT (which creates a
resource at a given URL). These concepts do apply even though
what's being served isn't a "file" in the traditional sense.