Bottom line to me is that HTTP is a pretty heavyweight and bloated protocol, whereas FTP is a lot cleaner. So for raw data transfer I'd always prefer an FTP server. Password security is an issue because it's perhaps not as good as HTTPS - but then with HTTPS aren't we getting into pay-through-the-nose server certificate territory? And it's certainly no worse than HTTP. Of course it depends on your actual intended setup anyway - if on a LAN or over a VPN then plain-text password transfer may be less of an issue, or maybe anonymous FTP access is fine for a particular situation anyway. It's worth thinking about what may be between your clients and servers too. HTTP data is much more likely to be transparently cached somewhere along the line (which may have security implications), but the flipside is that port 80 is generally less likely to be blocked than port 21 for ftp. My memory's hazy here - I wrote both an FTP client and server a few years ago for a particular project - but I seem to remember that there are essentially two methods of file transfer for FTP - one where the server makes the data connection back to the client (which from a server's point of view is more secure) and one where the server tells the client what port to connect to for a transfer and the client then opens a connection to that port on the server. The latter method really messes up firewalls :) Determining file type etc. is pretty much a non-issue I'd say; it's a higher level server function than the raw protocol, so it shouldn't affect file transfer and only dictate what the server ultimately does with the file. REST is fantastic for FTP and was historically a big reason why I hated HTTP servers for file transfer over FTP. However, not all FTP servers always support it which is a shame. HTTP does support restarts, at least in a lot of later incarnations - I think the problem's more that a lot of common browsers typically weren't smart enough to cope with it. I've used wget to do restarts when transferring data from HTTP servers before though. Agreed - and there are some nice FTP clients out there if your users aren't into typing stuff on the commandline (Aside - I don't believe that the FTP protocol defines passing wildcards to the DELE command, and neither is there any form of 'MDEL' for multiple deletes, and RMD doesn't allow deleteing a directory unless it's empty. Deleting lots of files without a graphical client can be a pain!) I'm actually very anti-HTTP to be honest. Great for what it was originally intended for, but it really bugs me the way current view is "the Web is the Internet" and unless something can be hacked to run over HTTP then it isn't worth doing. Upload's even more of a mess from what I remember, requiring something at the server end (be it Perl, compiled CGI, Java or whatever) to handle and save the incoming data stream - i.e. there's no standard for actually saving an upload to the filestore. Similarly, if you do want to administer files behind a web server then the solution is going to be localised as there's no standard for that either. You may even have encoding issues when uploading a file, and we've all come across problems with referencing files by HTTP due to the protocol not allowing certain characters and some servers handling illegal characters differently to others. scp? Never used it. How portable is it to different platforms? cheers Jules

It was thus said that the Great Jules Richardson once stated: I consider FTP to be more convoluted than HTTP (having helped written a webserver and only briefly looked over the FTP specs) since under FTP there is support for differing file modes (stream, record, conversions between text formats, etc.) and setting up tranfers between multiple machines. HTTP is simple enough to use via telnet. Given http://boston.conman.org/2000/06/04.1 you can do: %telnet boston.conman.org 80 Trying 216.82.116.251... Connected to swift.conman.org. Escape character is '^]'. GET /2000/06/04.1 HTTP/1.1 Host: boston.conman.org (blank line, type nothing here) (server starts spewing data out at you) The complications arrise when you start using more of the features in HTTP/1.1, such as byte ranges, conditional requests (if the "file" hasn't changed since such-n-such a date, don't send anything), caching, etc. Not necessarily. You can sign your own certificates, but browsers will give a warning about an unknown certificate authority (someone other than Verisign & Co.). The money you pay is to repay the bribes the secure companies paid the browser makers to include their certificate. There's a reason for that---what a webserver serves up may not even *be* a file---it really depends upon the website in question, or even what part of the site you're uploading a "file" to. That's why most webservers farm out the uploading to an external process, although one could always write a module (say, for Apache) to handle it in-server. The intent really, is that a PUT method (of HTTP) "puts" a resource at the given URL. So, I could (although I've yet to do this), write a client that connects to boston.conman.org and issues: PUT /2004/05/28.2 HTTP/1.1 Host: boston.conman.org Content-type: application/x-mod-blog; charset="US-ASCII" Content-length: nnnn title: title of this post catagories: various catagories, blah blah <p>Here is a post I'm making today ... </p> And some piece of code on my server (as an Apache module, or an external program that Apache calls) will take the content and store it in the appropriate locations. The actual storage of entries in my online journal isn't a one-to-one file relationship, and the structure I'd use to upload an entry for a URL of http://boston.conman.org/2004/05/28.2 can't be the same as http://boston.conman.org/2004/05 as the latter contains entries for an entire month, and each entry (for the site to work) needs to be stored separately. That's why webservers require something on their end to handle and save the incoming data stream. -spc (I actually use email to update my site 8-)

On Fri, May 28, 2004 at 04:53:33AM -0400, der Mouse wrote: Yes. I didn't read the RFC. ENOTIME, ENOPATIENCE. 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. 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) [...] 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. 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. 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. Yes. ENOTIME. 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. 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.) $ 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/

On Friday 28 May 2004 03:53, der Mouse wrote: Since you seem to be in love with classic protocols, how about this... at least for non-anonymous transfers, you could just use kermit to transfer the file over an ssh connection. that'll handle all of your ftp "corner cases" that http doesn't support (btw, most http servers do support resuming file transfers these days), and adds functionality. I don't think even ftp supports some things like changing filesystem ACLs, or changing your password on the server, for instance. For anonymous transfers, the only thing I can see you'd want that http doesn't provide (assuming a server and client that support resuming) is transferring multiple files over a single TCP connection (I don't care about), or transfering record-mode files from something like VMS (shove them in an archive format that survives bit-mode transfers). Pat -- Purdue University ITAP/RCS --- http://www.itap.purdue.edu/rcs/ The Computer Refuge --- http://computer-refuge.org

It was thus said that the Great Patrick Finnegan once stated: It can, but by using the FTP SITE command to sneak then through. And since it's a site specific implementation, changing ACLs on a VMS FTP server will most likely be different changing ACLs on a UNIX FTP server. HTTP/1.1 can serve multiple requests on a single session; in fact, for HTTP/1.1 that's the default connection type. -spc (Okay, HTTP is complicated by the fact that there are three versions of the protocol defined ... )

No. I don't really like it all that much as a language in its own right, and I strongly dislike some aspects of the culture that has grown up around it. I had trouble dealing with no command-line editing, so I patched DCL to add it (and in the process discovered a bug, er, ahem, "undocumented limitation" in patch). When we switched from VMS to Unix, I _really_ missed ECL (what I called my patched DCL), so I added command-line editing to csh. What the result has become by the present day is still my preferred shell; it differs from tcsh in a number of important-to-me ways. (One of my back-burner projects is building a new shell entirely de novo....) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse(a)rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

It was thus said that the Great der Mouse once stated: 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/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]. 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.

If the data isn't sensitive and only the login information needs to be protected, you could also use ssh2 to tunnel port 21 and then just use a regular ftp client and daemon, tunneled through an ssh2 client and daemon. -- ---------------------------------- personal: http://www.armory.com/~spectre/ -- Cameron Kaiser, Floodgap Systems Ltd * So. Calif., USA * ckaiser(a)floodgap.com -- If the dictionary misspells a word, how would you know? -- Steven Wright ---

It was thus said that the Great Paul Koning once stated: You haven't had to run wu-ftpd. Almost as bad as sendmail. -spc (hate hate hate wu-ftpd ... )

At 14:44 28/05/2004 -0400, Bob Lafleur wrote: This used to be a problem with the old BBC Micros I used to use - if left powered up for months (like when I was running a multi-user BBS) some cap in the PSU would burn out in some manner, although the machine carried on working. The next time you did happen to switch it off then on, it would take varying amounts of time to actually fire up - from several seconds to over 24 hours in one case.