From owner-freebsd-questions Tue Feb 6 14:37:09 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA19376 for questions-outgoing; Tue, 6 Feb 1996 14:37:09 -0800 (PST) Received: from pelican.com (pelican.com [206.16.90.21]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA19349 for ; Tue, 6 Feb 1996 14:36:55 -0800 (PST) Received: by pelican.com (Smail3.1.29.1 #10) id m0tjw0F-0000SMC; Tue, 6 Feb 96 14:36 PST Message-Id: From: pete@pelican.com (Pete Carah) Subject: Re: apache server To: brandon@tombstone.sunrem.com (Brandon Gillespie) Date: Tue, 6 Feb 1996 14:36:47 -0800 (PST) Cc: questions@freebsd.org In-Reply-To: from "Brandon Gillespie" at Feb 6, 96 02:54:23 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-questions@freebsd.org Precedence: bulk Brandon Gillespie writes: > > If you want to have each site show as http://unique.site.name/xxxxx, > > this problem is NOT solvable by anything on the server end except for > > multiple IP addresses. The problem comes from a shortcoming in the > > http protocol itself; the base site name is not forwarded to the host > > when the http query is made. This is because the CERN/UIUC folks way back > > a few years ago, when they invented http thought that noone would ever > > want to do that, I guess... > Actually, the 'problem' has nothing to do with http whatsoever. Yes it does. > The > 'problem' is that when you get an opened TCP connection the ONLY > information you have is the IP address, you get the name by calling the > named and doing a reverse lookup. Wrong two ways 1. Apache doesn't do reverse lookups for this purpose. Neither does innd; reverse lookups are very expensive. Look at the apache startup code; wonder, for example, why it cores when a virtual domain is not in the *forward* nameserver yet (the sig 11 is a pure mistake, but it does show how they handle virtual hosts)... (and in the innd case, why you have to reload hosts.nntp whenever you change it...) Both of these do *only* forward lookups. 2. http could present the request as GET //site.domain/file but instead it presents it as GET /file Note that http clients all do this already for proxys; it isn't much of an extension to have them do it for all requests. >Since all IP addresses can only have > one authoritative name (additional names are aliases/cnames), you will > not know if the other end pointed to your machine with 'www.foo.com' or > 'www.bar.com'. HOWEVER, your machine can handle more than one IP > address, which is how it figures out that you are pointing to another > 'site'. Admittedly you could add to the HTTP protocol so the client > tells the server what the client thinks the server's name is, but this > would be horridly redundant, in general its best to distribute the load > and put different domains on different machines, a 486DX unix box can be > hacked together for virtually nothing. That is not the *real* problem. http could very easily have been formulated to handle this problem but the originators of http never thought it would explode into what it has :-) If the original problem statement had included shared servers it would probably have had the requested hostname included by default. It wouldn't really be that redundant (see next)... I know all the TCP stuff, and that cnames don't show. Remember that all TCP packets have at least 40 bytes of junk at the start, not counting the link-layer overhead. a domain name wouldn't be *that* much more. (and VJ compression doesn't help widely-spaced requests very much.) Just for interest, http/html was invented by a bunch of high-energy physicists (at CERN and UIUC) to pass papers around the net in a nicer way than email. (*really*) Since papers all reference each other (where's the original research come from, anyhow :-) the hypertext aspects were thrown in to make this easier. Commercial use, especially on the current scale, was never forseen at the beginning; it shows... > > another way involves CNAMEs and a chooser page but that's a kluge too). > > uhh, yeah, right. Look at http://www.caves.org/ among others... If you check with nslookup it is a pointer directly to an iquest server's primary address, not an alias. popmail is an even worse problem; it was *never* meant for what most isp's use it for these days. Talk about mixing domains... [btw - The actual pages are http://www.caves.org/~nss] > > One comment: keep the aliases to a minimum when virtual hosting, too many > can really slow down networking. That's why it is a P120 :-) At least one isp I've heard from in passing on another freebsd list has about 400 aliases and still nicely keeps up with a T1 (no, I don't remember who; I think he's in germany). -- Pete