httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject in progress: vhosts yet again
Date Sun, 05 Oct 1997 05:41:04 GMT
I can't stand it any longer.  I'm correcting vhosts.  I know it's past
feature freeze and I know you all may veto the code that I'll produce, but
I don't care, I have to try.  I can't stand these stupid PRs and the
confusion the current situation causes our users. 

My definition of correctness goes something like this: 

The directive "NameVirtualHost a.b.c.d:p" declares an addr:port pair on
which HTTP/1.1 Host: header comparison, and Request-URI comparison is used
to determine which vhost to use.  This directive partitions all possible
ip address:port pairs into those which are ip-based vhosts and those which
are name-based vhosts. 

VirtualHosts occurring later in the config file have less precedence than
VirtualHost occuring earlier in the file.  THIS IS THE COMPLETE OPPOSITE
OF THE CURRENT CODE.  I am chosing this because it is how other bits of
our config language work already, it's trivial to change.

The declaration <VirtualHost a b c> is identical to declaring <VirtualHost
a>, then <VirtualHost b>, then <VirtualHost c> and copying the nested
definitions.  Even more specific, if a resolves to two addresses a1
and a2 then <VirtualHost a> is the same as <VirtualHost a1> followed by
<VirtualHost a2>.

I am *relaxing* the requirement that a server_rec be either a name-vhost
or an ip-vhost and not both.  It is possible now for a server_rec to
be a name-vhost on some addresses, and an ip-vhost on others.

port-vhosts are a figment of someone's imagination.  But I have an
imaginary friend too, so I'll pretend they exist.

So for example:

        NameVirtualHost 10.0.0.1
        NameVirtualHost 10.0.0.2:8080
        NameVirtualHost 10.0.0.4

        <VirtualHost 10.0.0.1>
            ServerName vhost1
        </VirtualHost>

        <VirtualHost 10.0.0.1 10.0.0.3>
            ServerName vhost2
        </VirtualHost>

        <VirtualHost 10.0.0.2 10.0.0.2:8080>
            ServerName vhost3
        </VirtualHost>

        <VirtualHost 10.0.0.2:8080>
            ServerName vhost4
        </VirtualHost>

        <VirtualHost 10.0.0.4>
            ServerName vhost5
        </VirtualHost>

Requests occuring on the addr:port on the left can possibly result in the
vhost on the right:

        10.0.0.1:80             vhost1 vhost2
        10.0.0.2:80             vhost3
        10.0.0.2:8080           vhost3 vhost4
        10.0.0.3:80             vhost2
        10.0.0.4:80             vhost5

vhost1 is the default for 10.0.0.1:80.  Requests on this address will only
ever consider vhost1 or vhost2 as possibilities.

vhost3 is the default for 10.0.0.2:8080.  Requests on this address will only
ever consider vhost3 or vhost4 as possibilities.

Requests on 10.0.0.2:80, 10.0.0.3:80, and 10.0.0.4:80 will *ALWAYS* go to
the server listed above.  Never will Host: or the Request-URI be considered.

Requests occuring on an address not listed will go to the global server
or to a _default_ server as appropriate.

Wildcard ports utterly suck.  But I'm guessing that you SSL weenies need
me to not screw them up.  Given that port-vhosting hasn't ever worked
correctly with name-vhosting I'm not at all concerned about making it
work now.  So here's what I'm asserting:

    NameVirtualHost has precedence over VirtualHost no matter what order
    they occur in.  Wildcard ports are valid on NameVirtualHost.

So, for example:

    NameVirtualHost 10.0.0.1:*

    <VirtualHost 10.0.0.1:8080>
	ServerName vhost1
    </VirtualHost>

    <VirtualHost 10.0.0.1:*>
	ServerName vhost2
    </VirtualHost>

    <VirtualHost 10.0.0.1:80>
	ServerName vhost3
    </VirtualHost>

Everything there will be treated as name-vhosts, with these possibilities:

    10.0.0.1:80		vhost2 vhost3
    10.0.0.1:8080	vhost1 vhost2

vhost2 is default for 10.0.0.1:80, vhost1 is default for 10.0.0.1:8080.

If the server also had a port 8888, and you wanted <VirtualHost
10.0.0.1:8888> to be an ip-vhost then tough luck.  You have to list each
port individually in NameVirtualHost statements.

Now!  Ok how simple can that be, it took me way too long to describe it,
right?  Well I think if you forget everything you know about vhosts and
just learn this:

    The NameVirtualHost directive declares addresses that enable the
    use of ServerName, ServerAlias, and ServerPath for determining
    what <VirtualHost> to use.  All other addresses do not use those
    directives.

    Earlier has higher precedence than later.

There's only a handful of examples which are of any interest anyhow.

Ok back to coding.

Dean

P.S. I'm also moving all of this into a new file http_vhost.c.


Mime
View raw message