httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
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:


            ServerName vhost1

            ServerName vhost2

            ServerName vhost3

            ServerName vhost4

            ServerName vhost5

Requests occuring on the addr:port on the left can possibly result in the
vhost on the right:             vhost1 vhost2             vhost3           vhost3 vhost4             vhost2             vhost5

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

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

Requests on,, and 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:


	ServerName vhost1

	ServerName vhost2

	ServerName vhost3

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

vhost2 is default for, vhost1 is default for

If the server also had a port 8888, and you wanted <VirtualHost> 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

    Earlier has higher precedence than later.

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

Ok back to coding.


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

View raw message