ftp vs http vs scp

From: der Mouse <mouse_at_Rodents.Montreal.QC.CA>
Date: Fri May 28 03:53:33 2004

>> For example, FTP understands the difference between a unix-style
>> "stream of bytes" file, and a structured one such as might be found
>> under VMS (or any of several other OSs) -- and can deal with the
>> difference.
> You are refering to "binary" versus "ascii" mode in ftp?

Well, I didn't write it, but I do know something about FTP - for
example, I've read its defining RFC, which appears to be more than you
bothered to do.

Yes, ASCII text versus something else[%] is one of the simplest of the
ways in which FTP does as described; it can do more, too (a lot more).
If you care what FTP can do, there is really no substitute for reading
RFC 959; for these purposes, I recommend you start with section 3.1.

[%] The something else is often called "binary" by clients, but there
    is no such thing in the protocol. When told to use "binary", I
    have seen (depending on the client) "TYPE I" and "TYPE L 8"; which
    is more appropriate depends on what you really mean by "binary".

> http can do the same. It is possible to specify encodings, charsets,
> ... in the http headers.

HTTP can do the same only to a point.

For example, FTP recognizes three types of file structure, only one of
which is an even moderately close match to an HTTP data stream.
Quoting from RFC 959 section 3.1.2:

         In addition to different representation types, FTP allows the
         structure of a file to be specified. Three file structures are
         defined in FTP:

            file-structure, where there is no internal structure and
                                the file is considered to be a
                                continuous sequence of data bytes,

            record-structure, where the file is made up of sequential

            and page-structure, where the file is made up of independent
                                indexed pages.

> The problem may be that ftp uses a "strange" way to handle
> connections. You have one TCP stream for control and an other for
> data.

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

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.

> Depending on active or passive ftp the data connection is opened from
> the server to the client or vice versa. (IIRC)

You do. (Recall correctly, that is.)

> http uses only a TCP connection from the client to the server on port
> 80.

Not necessarily; it can use any port - 80 just happens to be the

> An other issue may be that ftp allways transferes clear text
> passwords.

If you think this you need to read RFC 2228 and to some extent 2773;
for the moment, just read my response to the next quote.

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

> All http clients support https.

This is false. I, for example, run lynx, and on two separate occasions
I have looked into convincing it to support SSL; in each case, I got
about four levels deep in tools-to-build-the-tools before running into
a requirement for something ridiculously heavyweight - perl, I think -
and abandoning the attempt.

/~\ The ASCII der Mouse
\ / Ribbon Campaign
 X Against HTML mouse_at_rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Received on Fri May 28 2004 - 03:53:33 BST

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