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.
Received on Fri May 28 2004 - 13:04:45 BST