comments on vhosts-in-depth

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

>    In the absence of any Listen directives, the (final if there are
>    multiple) Port directive in the main_server indicates which port
>    Apache will listen on.
>    
>    If one or more Listen directives are used an existing Port directive
>    is overwritten (eg. Apache doesn't bind to the given port number), but
>    the Port and ServerName directives for any server main or virtual are
>    used when generating URLs such as during redirects.

Hmm, is this any more clear?

    The main_server Port directive has two functions due to legacy
    compatibility with NCSA configuration files.  One function is
    to determine the default network port Apache will bind to.  This
    default is overridden by the existence of any Listen directives.
    The second function is for generating absolute URIs in redirects.

    Unlike the main_server, vhost ports <i>do not</i> affect what
    ports Apache listens for connections on.

...

>    Unless a NameVirtualHost directive is used with a specific IP address
                                                    for
>    the first vhosts with that address is treated as an IP-based vhost.
               vhost

>    If name-based vhosts should be used a NameVirtualHost directive must
>    appear with the IP address set to be used for the vhosts. In other
>    words, if you want to use one or more name-based vhosts for a specific
>    IP address a NameVirtualHost directive with that IP address must be
>    inserted in your configuration file.

Somehow we've lost the definition of name-based versus ip-based.  Or
is it in vhost-examples ?  I haven't read that yet.

>    After parsing the VirtualHost directive, the vhost server is given a
>    default Port equal to the port assigned to the first name in its
>    VirtualHost directive. The complete list of names in the VirtualHost
>    directive are treated just like a ServerAlias (but are not overridden
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    by any ServerAlias statement). Note that subsequent Port statements
>    for this vhost will not affect the ports assigned in the address set.

This is subtly wrong.  If you have:

    a.foo.com	10.0.0.1
    b.foo.com	10.0.0.2

and

    <VirtualHost a.foo.com b.foo.com>
    ...
    </VirtualHost>

Then connections to 10.0.0.1 would treat "a.foo.com" as a server alias,
but would not consider "b.foo.com".  Conversely for 10.0.0.2.

>    Due to a fast hashing function the overhead of hashing an IP address
>    during a request is minimal and almost not existent. Additionally the
>    table is optimized for IP address which vary in the last octet.
                               addresses

>    Any vhost that includes the magic _default_ wildcard is given the same
>    ServerName as the main_server. There is no relation to any
>    NameVirtualHost directive.

I'm not sure what you mean with the second sentence here.  The first
is correct.

>    If the lookup fails (the IP address wasn't found) the request is
>    served from the _default_ vhost if there is such a vhost for the port
>    to which the client sent the request. If there is no matching
>    _default_ vhost the request is served from the main_server.
>
>    If the lookup succeeded (a corresponding list for the IP address was
>    found) the next step is to decide if we have to deal with an IP-based
>    or a name-base vhost.
>    
>     IP-based vhost
>     
>    If the entry we found has an empty name list then we have found an
>    IP-based vhost, no further actions are performed and the request is
>    served from that vhost.
>    
>     Name-based vhost
>     
>    If the entry corresponds to a name-based vhost the name list contains
>    one or more vhost structures. This list contains the vhosts in the
>    same order as the VirtualHost directives appear in the config file.
>    
>    The first vhost on this list (the first vhost that appears after the
>    corresponding NameVirtualHost directive in the config file) has the
>    highest priority and catches any request to an unknown server name or
>    a request without a Host: header.
>    
>    If the client provided a Host: header the list is searched for a
>    matching vhost and the first hit on a ServerName or ServerAlias is
>    taken and the request is served from that vhost. A Host: header can
>    contain a port number, but Apache always matches against the real port
>    to which the client send the request.
                         sent

>    If the client submitted a HTTP/1.0 request without Host: header we
>    don't know to what server the client tried to connect and any existing
>    ServerPath is matched against the URI from the request. The first
>    matching path on the list is used and the request is served from that
>    vhost.
>    
>    If no matching vhost could be found the request is served from the
>    first vhost with a matching port number that is on the list for the IP
>    to which the client connected (as already mentioned before).

Yup correct up to here.

>    The vhost resulting from the above search is stored with data about
>    the connection. We'll call this the connection vhost. The connection
>    vhost is constant over all requests in a particular TCP/IP session --
>    that is, over all requests in a KeepAlive/persistent session. In other
>    words the matching process is only done one for each KeepAlive
>    session.

We don't do this any longer ... we keep a pointer only to the list of
names and waltz down that list again for each request on one connection.
The name lookup has to be done for each request; but the IP lookup doesn't
have to be done more than once.

>     Absolute URI
>     
>    The URI from the request is check if it is an absolute URI, that is it
>    includes http://hostname/, then an attempt is made to determine if the
>    hostname's address (and optional port) match that of the connection
>    vhost. If it does then the hostname portion of the URI is saved as the
>    request_hostname. If it does not match, then the URI remains
>    untouched. Note: to achieve this address comparison, the hostname
>    supplied goes through a DNS lookup unless it matches the ServerName or
>    the local IP address of the client's socket.

Ugh, yeah it does stuff like this, but wow is it a pain to explain.

>      * If two IP-based vhosts have an address in common, the vhost
>        appearing first in the config file is always matched. Such a thing
>        might happen inadvertently.

Add:

    The server will give a warning in the error_log when it detects this.

>      * The last name-based vhost in the config is always matched for any
>        hit which doesn't match one of the other name-based vhosts.

Remove this one... this is how it used to work.

>      * A _default_ vhost or the main_server is never for a request with
>        an unknown or missing Host: header if the client connected to an
>        address (and port) which is used for name-based vhosts, eg. in a
>        NameVirtualHost directive.

I think you mean to add "is never matched for a request" on the first line.

>      * A DNS lookup is always required for the main_server's ServerName
>        (or to generate that if it isn't specified in the config).

Actually, if ServerName is specified, as of the 1.3 code it no longer has
to do any DNS for the main_server.  This is because it doesn't care what
the main server's address is.

Looks good otherwise.

Ok on to your examples next.

Dean