Name/address virtual hosts

[Rodent of Unusual Size <co...@decus.org>]

    Having finally gotten some additional iron and addresses (thanks and
    kudos to my CEO!), I'm trying to get a real handle on understanding
    some of the vhost issues.  Dean's been complaining about them, and
    providing fixes, and holding forth on the subject for months, but
    much of it went right over my head, and I didn't have resources to
    delve deeper.  Now I do, and I think I'm beginning to see why he
    gibbers so. <g>

    As I recall, there are limitations on how name-vhosts and
    address-vhosts can be intermixed, but I can't find clear
    documentation on the restrictions.  I tried snooping through the
    online docs, but they don't describe the 1.3 matching algorithm yet.

    I'm getting results I don't understand.  I'm working with two
    addresses and five names:

     10.0.0.1 -> A
     10.0.0.2 -> B
                 C -> A
    		 D -> B
    		 E -> B

    I have the following in my configuration files:

     ServerName localhost (for the main server)
     Listen 10.0.0.1:80
     Listen 10.0.0.2:80

    I have name-based <VirtualHost> containers for all of these (none
    are listed by IP address), with ServerName and ServerAlias in each
    set to the name of the vhost.  And here's what I get:

     http://A/ -> DocumentRoot from <VirtualHost A>
     http://B/ -> DocumentRoot from <VirtualHost B>
     http://C/ -> DocumentRoot from <VirtualHost B>
     http://D/ -> DocumentRoot from <VirtualHost B>
     http://E/ -> DocumentRoot from <VirtualHost A>

    This changes if I alter the order of the <VirtualHost> containers.

    Clearly the name-vhosts aren't even in the running.  There is
    obviously some basic flaw in my understanding which has heretofore
    been concealed by my working strictly with name-vhosts.  Yarg..

    Leaving the additional dimensions (e.g., port numbers) out of it,
    what I would have *expected* to happen was something along the lines
    of

     1. Does rlookup("Host:") == IP of interface request arrived on?
         NO: [a] use _default_ vhost for that address, or for whole server
	     if no per-address _default_ defined
    	 YES: goto [2]

     2. Is there a <VirtualHost> that matches "Host:"?
         NO: go to [a]
    	 YES: use it

    I feel as though there is a crucial linchpin piece missing from the
    algorithm - like maybe not being able to specify a per-address
    _default_ container..?  Maybe the linchpin is missing from my
    brain..

    #ken    P-P}

Re: Name/address virtual hosts

[Dean Gaudet <dg...@arctic.org>]

A global "servername localhost" effectively disabled name-vhost support. 
The global servername is essentially the addresses on which you want to
allow name-vhost support.  This is not the most clear ... but it should be
how the code works... we could make it more clear by having an explicit
NameVHostAddr thing. 

Note that there is no concrete support as of yet for multiple pools of
name-vhost addresses.  i.e. you can't have a default for each ip.  Well
maybe you can, I've never checked to see if you can fool it somehow.

The server gives no errors when vhosts overlap ips, it assumes you meant
to shoot yourself in the foot.  The actual host which is active is
dependant on ordering.  In 1.2 it would be the last one in the file, it
should be the same in 1.3... but your results don't seem to show that (I'm
assuming you defined vhost A first then B, C, D, E).

On Sat, 27 Sep 1997, Rodent of Unusual Size wrote:

>      1. Does rlookup("Host:") == IP of interface request arrived on?

We do not want to do a lookup of the Host: header at all.  The code in
there which does that affects the proxy (and is imho lame), and should
have no effect on valid hostnames.  DNS lookups kill performance. 

>          NO: [a] use _default_ vhost for that address, or for whole server
> 	     if no per-address _default_ defined
>     	 YES: goto [2]
> 
>      2. Is there a <VirtualHost> that matches "Host:"?

This is where the code starts.  Only if it's a name-vhost though.

>          NO: go to [a]
>     	 YES: use it
> 
>     I feel as though there is a crucial linchpin piece missing from the
>     algorithm - like maybe not being able to specify a per-address
>     _default_ container..?  Maybe the linchpin is missing from my
>     brain..

As I said above you may be able to do this already, but I suspect not. 
The per-address default would simply be the first vhost with that address
(first means it shows up in the search last) and it should include
"ServerAlias *" and "ServerPath /".  The change to make this work may be
trivial. 

Dean