ftp vs http vs scp

From: Sean 'Captain Napalm' Conner <spc_at_conman.org>
Date: Fri May 28 13:04:45 2004

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

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


        which describes a vacation I took through northern Florida a few
        years ago. Not even


        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

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:37:13 BST