Subject: Re: Anonymous passwords

From: Evan Champion <[email-masked]>
Date: Sat, 01 Jun 1996 20:19:45 -0400

At 04:14 PM 01/06/96 -0700, you wrote:
>I've just spent the morning going through the xferlog looking at the
>passwords supplied on our system for the last month, and find a huge
>number that are still set to the defaults mozilla@, WWWuser@ and
>Netscape@.

While in general all I want to know is a date and time and what IP someone
came from (that way I can contact the admins at the site with the relevant
info to track someone down), providing garbage information like Netscape and
co. do really bothers me.  Netscape should NOT even given an option to login
with those fake names.  It should disable FTP access until you configure an
e-mail address.

Of course, this brings up the whole issue of how do you prove who someone is.

identd is useless.  You can't rely on any user-provided e-mail address being
correct.  So what do you do?  Require that someone have a Verisign
certificate to login to a server?

While writing this message, I started thinking about requiring digital IDs
to login to anonymous file servers and the more I thought about it the more
I liked the idea.  I took a trip to Verisign and they will be offering Class
1 digital IDs for non-commercial use for _free_.  Class 1 IDs are the lowest
level and don't offer any guarantee that the owner is who they say they are,
but they do sort of "write in stone" that a given user has a given e-mail
address.  That is at least better than what we have now, and since it's free
for non-commercial use, it would become "lowest common denominator" security
and should be good enough for most anonymous FTP access (you could always
require a higher security ID if you want).

The problem would be that you would probably end up serving files via HTTP
rather than FTP as web servers are already designed for this sort of thing.
That's fine by me -- both protocols can do the job just as well, with the
only problem being that it isn't quite as nice to get files via HTTP if
you're stuck in text mode.  What you could do is set up your server so that
certain directories would be wide open, and others would allow anyone in who
could provide a digital ID of whatever level is required (Verisign lists
Class 1 through 4 with 4 being the most secure).

Evan
--
Evan Champion            * Director, Network Operations
mailto:[email-masked] * Directeur, Exploitation du reseau
http://www.synapse.net/  * Synapse Internet

---

From: Mitch Wright <[email-masked]>
Date: Sat, 1 Jun 1996 21:31:24 -0700

/* Evan Champion [[email-masked]] writes: */

>with those fake names.  It should disable FTP access until you configure an
While to some extent I agree, you are being short-sited on the use of web
browsers.  There is no guarantee that the browser user even has an E-mail
address.  It is certainly not a requirement to surf the we.  Or consider a
web browser in a coffee shop, or one in kiosk mode.  The person there may
have an E-mail address but can't reconfigure the browser.

None the less, I think it would be a nice feature to be able to supply a
set of regex's that are matched against an anonymous users' password and
lets the server take some action like denying access, adding additional
privileges, and so forth.

-- 
do svidaniya,

  ~mitch

---

From: Evan Champion <[email-masked]>
Date: Sun, 02 Jun 1996 01:07:14 -0400

> have an E-mail address but can't reconfigure the browser.

If it is in a coffee shop, just make it the address for the store owner, or
some generic account, etc.  But even then, we're talking about anonymous FTP
access...  how often would a guy at a kiosk be FTP'ing files?

Also note that if a what you want is to restrict access to valid e-mail
addresses, perhaps you don't want people from kiosks logging in to your
FTP server.  People at kiosks are a lot harder to track than home etc.
users who are much more sedentary.

> privileges, and so forth.

That would be nice.

Evan

---

From: Mitch Wright <[email-masked]>
Date: Sat, 1 Jun 1996 23:45:54 -0700

>some generic account, etc.
>
But then what's the point of not having Mozilla@ or whatever.  I just wanted
to point out that there are times when there just isn't a real E-mail address
associated with a person browsing the web.

>But even then, we're talking about anonymous FTP
Not too often, but consider:

		ftp://ftp.somesite.com/some-product/README

While going through http makes more sense in this case, there are still
sites out there that link into their ftp areas for information. 

>users who are much more sedentary.
Realistically though, how often are you using that information to track 
a user anyway?  I mean really, its not like it isn't easily forged.
Someone earlier pointed out that they were more interested in the source
address than the user's E-mail address.  I think most people are.

If I'm interested in who the people are, I don't let them use anonymous ftp.
If I *really* care, they also don't get to use reusable passwords.

>> privileges, and so forth.
Where this becomes a particularly interesting feature is that you might
be able to detect a person coming in via a web browser and then "redirect"
them over to the http server.

Personally, at the moment I prefer routing all my file downloads through the
ftp server as it is a single entry and logging point for those downloads and
serves as a lowest common denominator as well.  An issue I'll be looking at
soon is using a web browser to access my ftp server that is using one-time
passwords via SNK, SKey, ...

-- 
do svidaniya,

  ~mitch

---

From: Evan Champion <[email-masked]>
Date: Sun, 02 Jun 1996 11:03:50 -0400

> sites out there that link into their ftp areas for information.

There are VERY few sites that do that still.  The only case where I know
that sort of thing is done on a regular basis is for a smaller shareware
program, but even then it is more likely to be found on Simtel.Net etc.
which is fronted by a web interface.
 
> address than the user's E-mail address.  I think most people are.

I think that since you can't do anything useful with e-mail addresses today
we are forced to look at source addresses.  If we could actually trust
e-mail addresses, maybe we would use them more.

> them over to the http server.

That would be nice.  How could that be implemented in the present FTP server
protocol without breaking too much?

> passwords via SNK, SKey, ...

You could just as easily do it the other way -- route all your file downloads
through an HTTP server.  I personally have my system set up so that the FTP
drive is mounted in to the web space so that useres can access it either way.
I figure it is more efficient if the guy is already on the web server to pull
the files from the web server rather than opening up a new FTP connection.

Evan

---

From: Chin Fang <[email-masked]>
Date: Sun, 2 Jun 1996 10:24:14 -0700 (PDT)

Correct me if I am wrong.  With web browsers, in most cases, providing
the resource hungry anonymous ftp is not only unnecessary, but also
requires a well equipped server.  If most of the tasks that
traditionally are accomplished via anonymous FTP can be done using web
page download, why bother with this issue?  If you want
passwords/email addresses etc, whatever their worth is, setting up a
Basic Auth should do an even better job than fiddling with the FTP
server and protocal itself.

Chin Fang
[email-masked]

---

From: Evan Champion <[email-masked]>
Date: Sun, 02 Jun 1996 13:51:15 -0400

> server and protocal itself.

That was sort of my point -- it may be a better idea to just stop offering
anonymous FTP access and put it all out via HTTP.  As I said, we presently
offer our entire FTP space via HTTP as well as anonymous FTP.  We are
starting to look in to only offering it via HTTP, however, to among other
things discourage people from mirroring our site.  I think it is very
possible that within 6 months we might not offer anonymous FTP access at
all.

Given that web servers and clients are already set up to handle things like
digital IDs, I personally thing that it is the better direction to take in
the long run.  That way you can have whatever level of security you like:
real anonymous where only the IP is logged, varying levels of digital ID
security, and possibly include password authentication.

With new servers and clients, you don't even need FTP service for people
to update their web documents (the main use for our FTP server).  Netscape
Gold can sync up its document set with the new Netscape servers without
having to use FTP.  I think when that becomes more available we might not
allow FTP at all except for internal use.

Evan

---

From: Mitch Wright <[email-masked]>
Date: Sun, 2 Jun 1996 13:31:21 -0700

>There are VERY few sites that do that still.  The only case where I know
Ok, I guess sites like netscape don't count then.  Or all the bloody
search databases out there (Yahoo! InfoSeek, AltaVista, ...).

>e-mail addresses, maybe we would use them more.
That's not likely to happen any time soon.

>protocol without breaking too much?
Sure, why not?

>> ...as it is a single entry and logging point for those downloads and
>through an HTTP server.
Tell me how to get the /usr/ucb/ftp command to talk to an HTTP server and
I'll agree.  A web browser can talk to both, but FTP clients (WS-FTP, ...)
only talk to ftp server.

Plus, I don't think I've seen an MGET equivalent on a web browser.

-- 
do svidaniya,

  ~mitch

---

From: Mitch Wright <[email-masked]>
Date: Sun, 2 Jun 1996 13:34:04 -0700

/* Chin Fang [[email-masked]] writes: */

>requires a well equipped server.
>
Why do you think an ftp server has to be any better equipped than an
http server?  It also doesn't help people that can't use a web browser
and only have FTP client software.

-- 
do svidaniya,

  ~mitch

---

From: Mitch Wright <[email-masked]>
Date: Sun, 2 Jun 1996 13:42:38 -0700

>anonymous FTP access and put it all out via HTTP.  As I said, we presently
I disagree, if for nothing else, backwards compatibility.

>things discourage people from mirroring our site.  I think it is very
Why would that discourage them?  There are alot of web-mirror programs
out there.  Actually, I think it is easier to mirror a web site than a
FTP site.

>security, and possibly include password authentication.
I agree that distribution via the web has many advantages and is quite
likely going to take over the duties of the average anonymous ftp server.

>allow FTP at all except for internal use.
If you are running a Netscape server (most people aren't) then that's fine.
And for your site that might be all well and good, but as a general direction
I don't believe so. FTP will be around for some time.

-- 
do svidaniya,

  ~mitch

---

From: Evan Champion <[email-masked]>
Date: Sun, 02 Jun 1996 17:00:17 -0400

> search databases out there (Yahoo! InfoSeek, AltaVista, ...).

I can't think of anything at Netscape that a guy at a kiosk would want to
FTP, or rather I can't think of anything at Netscape that a kiosk would
let a guy FTP.

That is something that always bothered me about Netscape's site.  They sell
these wonderful web servers and they've got a very good web network going
(very fast etc.) but they serve all their software via FTP, on sites that
are overloaded and half the time you can't even get a connection opened.

I went on to AltaVista to find the number of documents referenced via
FTP and while it may just have been due to the sorts of words I had it
search on, I couldn't find _any_.

I suspect that it is because these engines tend to search only the web
and not FTP servers.  I don't think I've seen any that mention that they
search FTP servers.

> >That would be nice.  How could that be implemented in the present FTP 
> >server protocol without breaking too much?

> Sure, why not?

I'm thinking of what happens when an FTP client receives an unknown
message?  Would it ignore it or close the connection?

> I'll agree.  A web browser can talk to both, but FTP clients (WS-FTP, ...)

There's no reason why someone couldn't design a more /usr/bin/ftp-like
web browser for accessing file directories.  And plus, there's always
Lynx.

> Plus, I don't think I've seen an MGET equivalent on a web browser.

That's a big reason why I want to put my files up via HTTP only.  I'm
tired of people mirroring/leeching my archives for no good reason.  Can
you come up with a reason why 1 guy keeps pulling 500-1000 MIDI files
per day from my site?

Evan

---

From: Mitch Wright <[email-masked]>
Date: Sun, 2 Jun 1996 14:57:59 -0700

>FTP, or rather I can't think of anything at Netscape that a kiosk would
They are likely to get to the download area and hit README's and alike.
You are right though, transferring a file would be silly if even possible.
The kiosk owner might want to disable ftp just to avoid this to begin with.

>That is something that always bothered me about Netscape's site.  They
>
It would be interesting to know their reasoning.

>and not FTP servers.  I don't think I've seen any that mention that they
But you can enter urls and in in the process of searching web pages you
get to ftp:// type urls.

>message?  Would it ignore it or close the connection?
Depends on the client.  The pre-login message has the same effect.

>web browser for accessing file directories.  And plus, there's always
This is true, but there are already perfectly good apps like WS-FTP and
FETCH that people are using.  /usr/ucb/ftp is on my system.  I don't have
to go and get something else.

>you come up with a reason why 1 guy keeps pulling 500-1000 MIDI files
Sure, inconvenience the masses to stop one person.  Let's say I want to
download both emacs and gcc.  Using HTTP I get to ask for the first, 
wait some undetermined amount of time, and then ask for the second.  With
simple ole' ftp, I can login late at night, use MGET, and go to bed.

And again, don't think someone can't automate mirroring or mass copies 
from your web server.

Anyway, I think we'll just have to agree to disagree.

-- 
do svidaniya,

  ~mitch

---

From: Evan Champion <[email-masked]>
Date: Sun, 02 Jun 1996 21:45:25 -0400

> out there.  Actually, I think it is easier to mirror a web site than a

It's not.  I (legitimately) mirror a site using a web mirror program and
it is a real pain.  It is VERY slow.  It has to request every document
and then check to see if the document has changed from the one on disk
and then transfer it.  It also works as sort of a tree search -- you
start with the first document, then pull all the documents it references,
then all the documents those documents reference, etc.  Using mirror (via
FTP) is so much easier.

> I don't believe so. FTP will be around for some time.

You know as well as I do that as soon as Netscape does something everyone
and their dog will do it too.  It won't be long before every server supports
the page sync etc. capabilities of the Netscape servers.

Evan

---

From: Evan Champion <[email-masked]>
Date: Sun, 02 Jun 1996 21:55:41 -0400

> It would be interesting to know their reasoning.

I can't 
 
> But you can enter urls and in in the process of searching web pages you

Sure.  But then we're talking about FTP'ing files and not doing web
browsing.  If you want to FTP files, you need a computer to FTP them
on to.  If you have a computer to FTP them on to, you likely have a
unique e-mail address (or one of a few) for that computer ie: it is
no longer the kiosk in the mall situation.
 
> Depends on the client.  The pre-login message has the same effect.

Yes -- but the pre-login message uses the same code type as an existing
one doesn't it?  So the client should recognize what to do with it,
even if it is unanticipated.  What happens if we suddenly add a few
new codes to the FTP servers?  (I don't have the answer but perhaps
one day when I've got some time on my hands I'll hack my FTP server
to start sending out garbage result codes at various places and see
what happens).
 
> to go and get something else.

Lynx is built in to my system too :-)  (BSDI, and probably any of the
*BSD's have it).  Anyway, there is very little on my site except the
FreeBSD distribution that would be of use to a UNIX user (the FreeBSD
distribution is the one that is making me stop and think about this
because it is only really useful if there is a way to MGET files.)
 
> simple ole' ftp, I can login late at night, use MGET, and go to bed.

You could also run a client that supports multiple connections and pull
both files at the same time :-)

I think that probably with HTTP/1.2 where they are supposed to bring
in multiplexed connections, you should be able to just keep clicking
away and download however much you want all concurrently.

It only takes a few people to really screw things up for everyone.  I'm
going to start tracking some of these people and ban them from my FTP
server.  I've already hacked my ls to refuse to do recursive directory
listings to try to discourage mirroring.

> And again, don't think someone can't automate mirroring or mass copies

No, but it is a lot more trouble.
 
> Anyway, I think we'll just have to agree to disagree.

That's possible :-)  I'm not saying I'm right, it is just one viewpoint
out of many :-)

Evan

---

From: Evan Champion <[email-masked]>
Date: Sun, 02 Jun 1996 22:09:47 -0400

> > It would be interesting to know their reasoning.

Momentary brain lapse :-)  That should have read something like:

I can't think of any good reason.  Netscape HTTP servers are
perfectly capable of serving large files very efficiently.

Evan

---

From: Mitch Wright <[email-masked]>
Date: Sun, 2 Jun 1996 19:04:28 -0700

>and then check to see if the document has changed from the one on disk
I said easy, not better or faster.  As long as the http server supports
HTTP 1.0 you can mirror those pages.  With an FTP server you have to parse
out the days from the "dir" or "ls" commands and deal with them.  Output 
from a PC's ftpd is often different than that from a UNIX box.  Then what
about mirroring stuff from an AS/400?  Anyway, I think this discussion is
becoming a bit pointless.

>the page sync etc. capabilities of the Netscape servers.
Maybe.  Netscape is the leader today, but it's becoming clear that they
may not continue in that position.  And just because Netscape does something
doesn't mean it's good (E.g <blink>) and it doesn't mean it will become part
of the standard.  But yeah, that's a feature I become part of many HTTP
server.  I haven't messed with NS/Gold, but can you "upload" arbitrary files
such as product.zip?

-- 
do svidaniya,

  ~mitch

---

From: Mitch Wright <[email-masked]>
Date: Sun, 2 Jun 1996 19:47:44 -0700

>Sure.  But then we're talking about FTP'ing files and not doing web browsing.
>
Not at all.  I could register the URL for my company's information with
an ftp:// method.  Never underestimate the stupidity of users, especially
here on the net.

>If you have a computer to FTP them on to, you likely have a
Consider a PC either using ISDN or PPP to surf the web.  While it's likely
they have an E-mail address supplied by their ISP, it certainly is not a
requirement of any sort.  I think we'll see more and more of it.  Especially
if the $500 "internet PC" ever comes to pass.

>one doesn't it?
I'd have to look, but I'm pretty sure it spits the message out then returns
the code for the client to prompt the user for a username.  And, if you are
only doing it when you see something that looks like a web browser, it
really shouldn't matter much.

But in the end, I don't know for sure... just a thought.

>*BSD's have it).  Anyway, there is very little on my site except the
While I'm a UNIX hack, one must admit that the majority of people using
the net these days are on PC's and Macs running those things they try to
pass off as operating systems.

>both files at the same time :-)
There is always a way around it, but I strongly feel that one needs to keep
a certain amount of backwards compatability for a while.

>No, but it is a lot more trouble.
Not really.  The computer does all of the work.  It is certainly slower.
Of course they can open on multiple connections and pick up the speed.  :-)

>That's possible :-)  I'm not saying I'm right, it is just one viewpoint
Fair enough.

-- 
do svidaniya,

  ~mitch

---

From: Evan Champion <[email-masked]>
Date: Sun, 02 Jun 1996 22:48:04 -0400

> server.  I haven't messed with NS/Gold, but can you "upload" arbitrary files

Yup.  For an example, if you find the home page for cgi-lib.pl they have
an example up where you can upload files to it.  Actually, if I recall
you can do it on any Netscape 2+ (it doesn't have to be the gold version).

Evan

---

From: Judd Bourgeois <[email-masked]>
Date: Mon, 3 Jun 1996 01:05:39 -0400 (EDT)

> you come up with a reason why 1 guy keeps pulling 500-1000 MIDI files

If you don't want people copying your files, then don't put them up.  
Sheesh.  If you have to put the files up, then ban sites that mirror 
you.  Like this "1 guy" - apparently you know who he is, so tell him to 
blow off.

MGET is very practical for people on a low-bandwidth connection and the 
lack of it is the main thing I dislike about Netscape's FTP browser.  
Other than that I would use Netscape to browse FTP sites all the time, 
simply because it's the easiest thing to use.

shag

Judd Bourgeois     | When we are planning for posterity,
[email-masked] | we ought to remember that virtue is
Finger for PGP key | not hereditary.        Thomas Paine

---

From: Riku Saikkonen <[email-masked]>
Date: Mon, 3 Jun 1996 14:25:18 +0300 (EET DST)

[downloading multiple files in the background with HTTP]
>away and download however much you want all concurrently.

That isn't really a protocol issue but a client issue. I've never really
been able to figure out why Web browsers don't download stuff in the
background. On a Unix system it would be trivial to fork() a new process to
do the download, and let the user continue doing whatever he wants, and it's
possible on other OSes too.

But to return to FTP... MGET is really useful especially on slow
connections. (But getting one file whose URL (path) you know is usually
faster with HTTP (especially if the link has lots of packet loss) since you
don't have to send so many commands and read so many result codes (USER,
PASS, SYST, TYPE I, PORT, RETR, establish another connection) before you get
the file.)

Another thing that hasn't been mentioned is REST, i.e. transferring parts of
files. This is really useful sometimes, though it doesn't seem to always
work (I don't recall ever having trouble with a Unix FTP client to a Unix
FTP server, though). I don't think HTTP has an equivalent, though I'm not
sure.

And I've never really understood the same background transfer thing about
FTP clients and servers. The protocol allows them to multiplex; i.e. you can
do a RETR, and continue doing something on the FTP server while transferring
stuff in the background in the data connection (and you can have multiple
data connections transferring stuff). I don't know if wu-ftpd supports this
(I know one small&simple anon-only FTP server does), and I don't know of any
FTP clients that support this... But it's possible. I don't know why people
didn't implement it in the first place.

>listings to try to discourage mirroring.

Umm... Wouldn't a better way to discourage mirroring be to tell the users
(in the welcome banner or directory-specific messages or maybe READMEs) that
you don't want mirrors? If they don't believe you, maybe write a few
READMEs, INDEX files, or some not very useful material of your own,
copyright it, and tell the users that they aren't allowed to put it on other
FTP servers. That would even enable you to sue them for mirroring that
stuff, though you probably won't want to go that far.

Oh, and are you sure they all are mirroring? I don't really know if Web
search engines search ftp:// URLs at all, but if they do, they'd probably
use MGET at least at first...

If you really want to limit it, maybe put a limit on the number of
retrievals per connection? Though that may make the mirrorers get one file
per connection (with ftpget or ncftp (command line), handled with some
script), which is even worse... Maybe slow down the connection after a few
transfers (nice the ftpd process more, or sleep for a few seconds before
acknowledging a RETR, or something like that).

I think this mirroring is more a social problem than a technical one...

And if many people use the mirrors instead of your site directly, it may
actually help your network and server load. And it's a kind of cheap
distributed backup scheme ;). Mirrors hinder logging, yes, but so do FTP
caches (if a cache gets your file, you don't even know how many people got
the file from the cache). I don't think full logging of transfers is really
possible anymore (if it ever was - friends always acted as `caches' or
proxies for each other...).

If logging is really important to you, some sort of kind-of authenticated
scheme where the user has to fill a form (HTTP is useful for this) and read
a notice that says in big letters "Don't give this file to anyone!" :)
before he gets to download the file is probably your best bet. It's not
perfect, but nothing is... And the more difficult you make getting the file
from your site, the more will friends send it to each other directly.

>No, but it is a lot more trouble.

Lynx 2.5 supports it as a command-line option (getting and saving all URLs
that a HTML page references, recursively, with options to limit the
scope)... And there have been separate programs for doing it for a long
time.

But it's really useful sometimes, for example for the many HTTP servers
whose only documentation is on the Web; if you want to read all of it
without waiting for downloading each part, or if you want to print all of
it, it's useful to get it all and read it from the local disk.

-- 
-=- Rjs -=- [email-masked] - http://isil.lloke.dna.fi/rjs/

---

From: David Smith <[email-masked]>
Date: Mon, 3 Jun 1996 09:33:50 -0500 (CDT)

>From what I have seen ftpd and httpd take about the same amount of 
resources.  If anything httpd takes a bit more since it is usually not 
run from inetd and the extra deamons don't usually go away when the 
connection drops.

Also ftp clients tend to be more robust and effective in my experence 
that browsers.  I average almost twice the throughput using a good ftp 
client vs. a web browers, which means that the resource hit on the server 
will be higher, since the deamons will have to hang around longer.  Also 
at least in my case when trying to get a large file from a busy site I 
will log into a machine on a fast network and download it from there, 
rather than tie up the server (and my phone line) for a longer time, 
since I have a much better chance of getting a clean DL from a site on a 
T1 or T3 then over a phone line.  

-----------------------------------------------------------------------
David A. Smith                          | Baylor College of Medicine
Systems Services                        | Enterprise Services, MEDT1103
(713) 798-4559                          | One Baylor Plaza
Internet:  [email-masked]            | Houston, TX  77030

---

From: David Smith <[email-masked]>
Date: Mon, 3 Jun 1996 09:45:47 -0500 (CDT)

> But you can enter urls and in in the process of searching web pages you

Yes but most of them only search http:// references, there are already 
search engines for ftp and gopher sites.
 
> >you come up with a reason why 1 guy keeps pulling 500-1000 MIDI files

Yes, web browsers do it by using multipel connections, you really want 
the guy to try open 500-1000 connections at one time, just just write a 
script to get time though http, it isn't that hard, and I'm sure there is 
simple software to mirror a http tree.

---

From: Chin Fang <[email-masked]>
Date: Mon, 3 Jun 1996 08:21:54 -0700 (PDT)

Dear David,

[my stuff deleted]

> run from inetd and the extra deamons don't usually go away when the 

I agree with you only conditionally.  Yes, httpd also consumes memory,
but you don't need the forking overhead even if you use NCSA or its
sibiling such as Apache.

However, if you use a multi-threaded httpd such a phttpd or zeus, there
is no way a FTP deamon can beat httpd.  The later requires much less
memory, absolutely no forking overhead.

> T1 or T3 then over a phone line.  

Again, this depends on the httpd/browser combo that you use.  In general,
I have to agree with you.  Netscape is never as stellar as a good ftp 
client.

Chin Fang

---

From: Chin Fang <[email-masked]>
Date: Mon, 3 Jun 1996 08:44:24 -0700 (PDT)

Dear Mitch,

People who are facinated by Apache often are not aware of this NCSA
derivative is actually very slow and inefficient (it's versatile, all
right).  If you run a multi-threaded web server such as Phttpd for
Solaris or Zeus, you don't have multiple copies of httpd hanging
around, so you don't need as much memory, thus a less equipped server
would do.

On the other hand, unless you have a multi-threaded FTP server (I know
someone in Belgium is working on one), you have to pay the price of
forking, and many instances if the site is busy.

I won't use FTP for data distribution.  Period.  I won't use any
pre-forking HTTPD either. Period again.

Chin Fang

---

From: Mitch Wright <[email-masked]>
Date: Tue, 4 Jun 1996 00:07:51 -0700

>around, so you don't need as much memory, thus a less equipped server
I think it really depends on your needs.  If you aren't getting that many
hits per second, I don't think it makes that big of a deal and the features
will be what you want.

However, note that many large hit count sites run Netscape or Apache.

-- 
do svidaniya,

  ~mitch

---

From: Chin Fang <[email-masked]>
Date: Tue, 4 Jun 1996 01:40:35 -0700 (PDT)

Dear Mitch,

> hits per second, I don't think it makes that big of a deal and the features

Hmmm.. even the least powerful server that we run (as a teaser in fact)
gets 190k hits/day.  The rest of our servers in our server array typically
get around 350k hits/day.  They are no jokes already.  The total hits 
of our site often exceeds 1 million hits/day too.

> However, note that many large hit count sites run Netscape or Apache.

And they run an array of them, each one gets about a million or so,
which with a moderately equipped Sun SS5 (e.g. 64 MB RAM, two internal
HDs, one external HD, no virtual hosting at all) can easily handle,
assuming mostly static pages, moderate CGI.

Many of these so called large sites (e.g. Netscape) runs the far less
demanding single host configuration web server, which is no big deal by
itself, particularly on generously equipped machines.  Virtual Hosting
many sites on a computer brings the whole thing into a different ball
game.

Just the # of hits doesn't mean everything, it's an important factor,
but there are other factors that taxes the TCP/IP implementation of an
OS very heavily too and must be considered.

Netscape server is a hog, Apache can be one too.  Both are slow.

Chin Fang