On Fri, May 28, 2004 at 04:53:33AM -0400, der Mouse wrote:
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. I didn't read the RFC. ENOTIME, ENOPATIENCE.
For example, FTP recognizes three types of file
structure, only one of
which is an even moderately close match to an HTTP data stream.
Well. FTP was
developed at a time when there were only a few hosts on the
ARPAnet. Its roots are even older then TCP. Hosts with 36 bit architecture
and "9 bit bytes" like the PDP-10 (DECsystem-[12]) running TOPS-[12]0 or
whatever. So sometimes FTP needed to do a lot of translation to get the
file properties of one system maped to the file properties of an other
system. Today all the world is a 8/16/32/64 bit machine with 8 bit bytes
and flat files. As we are talking about HTTP, we are talking only about
this "modern" machines.
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).
With HTTP all you can do is close the
socket. An other difference
between FTP and HTTP is important in this case: FTP is session oriented,
HTTP not. So with FTP you need somthing to identify and controll the
session (one TCP stream) and somthing else to transfer the data (an
other TCP stream). With HTTP you request some data and get an answer.
That is all the protocol provides. (simplified)
HTTP also offers nothing like REST
[...]
Well, a Hyper Text Transfer Protocol is no File Transfer Protocol, but
it can be (ab)used to accomplish the same purpose in most cases:
Transport data from machine A to machine B. I know that FTP can do more
then only file transfer. Maybe we could call it more like File Transfer
and Remote File Manipulation Protocol.
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
default.
I am very aware of this. I omited this to keep the answer short and
simple. I think most readers of this list are aware that you can run any
service on any port, not only the default port.
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.
What FTP can do in theory
is one thing. What it is used for and how in
practice is an other thing. I mostly refered to the actual use of FTP.
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.
Yes. ENOTIME.
One googling (FTP SSL
client) turned up what looks lke a whole bunch of them;
Well, if there are clients
and servers is one thing. But is it used in
practice? I was refering more to actual use of ftps. (Much like telnets.
It exists, but everyone is using ssh.) I am using FTP and the Internet
for more then 10 years now, but never came acros ftps beside its entry
in /etc/services.
All http
clients support https.
This is false.
OK. Nearly all. The /usr/bin/ftp of
NetBSD is also a simple http client
and it doesn't support https. (At least it doesn't link the required
libraries and the man page talks only about http.)
I, for example, run lynx, and on two separate
occasions
I have looked into convincing it to support SSL;
$ uname -rs
NetBSD 1.6.1_STABLE
$ grep -i ssl /usr/src/pkgsrc/www/lynx/Makefile
# With SSL, lynx can get https:// and snews:// URL's.
CONFIGURE_ARGS+= --with-ssl
.include "../../security/openssl/buildlink3.mk"
$ ldd /usr/pkg/bin/lynx
/usr/pkg/bin/lynx:
-lz.0 => /usr/lib/libz.so.0
-lcurses.5 => /usr/lib/libcurses.so.5
-lssl.2 => /usr/lib/libssl.so.2
-lcrypto.1 => /usr/lib/libcrypto.so.1
-lintl.0 => /usr/lib/libintl.so.0
-lc.12 => /usr/lib/libc.so.12
--
tsch??,
Jochen
Homepage:
http://www.unixag-kl.fh-kl.de/~jkunz/