httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <br...@organic.com>
Subject Re: NameVirtualHost
Date Mon, 27 Oct 1997 06:42:02 GMT
At 01:35 AM 10/25/97 -0700, Dean Gaudet wrote:
>How about this:
>
>    In the absence of NameVirtualHost, Apache will do what everyone seems
>    to want it to do (but me).  That is it will guess that any overlapping
>    IP addresses are supposed to be name virtual hosts.
>
>    If any NameVirtualHost directives are present, then they must list
>    all addresses (any unlisted addresses result in an error).
>
>    "NameVirtualHost none" will disable NameVirtualHost support entirely.

For 1.3, I think this is best.

To make our jobs easier, maybe we could write a perl script which parses
the config files and somehow represents the configuration differently?  I.e. 

  parse_config www.virthost.com

would show

  Server available on IP address: w.x.y.z
  Listening on port 80
  Server is name-based; thus, browsers not supporting Host: will not see it
    Non-Host:-browsers will see www.original.com

At 01:45 AM 10/26/97 +0100, Rob Hartill wrote:
>Add a new directive. For want of a better name 'Service' will do for the
>demo:
>
>Service [hostname]:[ip]:[port] some-alias
>  with all the []s being optional   e.g.

This is the kind of direction I was thinking, too.

Justb for completeness, an error should be thrown if there's two similar
[hostname]:[ip]:[port] tuples used.  We could assume that a merge was
intended, but it's probably safer to assume it was an error.  A script like
I described above would still be useful.

>foreach x:y:z (Service) {
> score = 0
> if  (x!='' && x!=a) || (y!='' && y!=b) || (z!='' && z!=c)  do
next
>
> score = 1
> if  x!=''   score += 1   # a matching hostname is something to cheer about.
> if  z!=''   score += 2   # a matching port is better than a matching
hostname.
> if  y!=''   score += 4   # a matching IP is always the best choice.
>}

I don't like this.  I think it should be according to order in the config
file.  That's got less guesswork in it, I think, and someone might want
ports to supercede IP #.  I.e. if you had

::80		port80
:a.b.c.d:	abcd

in a row, then all requests to port 80 on any IP would get the port80
configuration, and all ports on a.b.c.d *except* port 80 would get abcd.  I
can think of situations where this makes sense.

Dean, on hashing: I think you could expand the ip and port part so that
each possibility is hashed whenever it's left nonspecific.  I.e. let's say
there's 5 IP addresses and a tuple of "bong.com::80"; hash 5 different
tuples, each with the same config.  Likewise you could treat
"bong.com:a.b.c.d:" by hashing for as many ports are listening. 

At the bottom folks put :::, and that's expanded (# of IP's) X (# of
ports).  And of course, to preserve order in the config files, if a tuple
is currently defined, don't redefine it.

Thus for every port and IP combination, you could get a list of valid
hostnames or regex matches.  Have two tables - a hash table with exact
hostnames, and a linear list of matching "*.host.com" file.  Search the
hash table, then search the linear list.  I have *no* problem telling folks
that if they want to optimize their vhost configurations, they should avoid
"*.host.com" and explicitly list all possibilities.  You could also go
crazy and ask DNS for all possible hosts at ".host.com" but I don't think
that's necessary :)

How does this sound?

	Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
"it's a big world, with lots of records to play." - sig   brian@organic.com

Mime
View raw message