httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rbo...@apache.org
Subject cvs commit: httpd-2.0/docs/manual/vhosts details.html fd-limits.html footer.html header.html index.html ip-based.html mass.html name-based.html
Date Sat, 22 Sep 2001 19:39:27 GMT
rbowen      01/09/22 12:39:27

  Modified:    docs/manual/vhosts details.html fd-limits.html footer.html
                        header.html index.html ip-based.html mass.html
                        name-based.html
  Log:
  w3c tidy to convert to xhtml
  
  Revision  Changes    Path
  1.12      +383 -368  httpd-2.0/docs/manual/vhosts/details.html
  
  Index: details.html
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/vhosts/details.html,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- details.html	2000/10/19 19:21:14	1.11
  +++ details.html	2001/09/22 19:39:26	1.12
  @@ -1,380 +1,395 @@
  -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
  -<HTML><HEAD>
  -<TITLE>An In-Depth Discussion of Virtual Host Matching</TITLE>
  -</HEAD>
  -
  -<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  -<BODY
  - BGCOLOR="#FFFFFF"
  - TEXT="#000000"
  - LINK="#0000FF"
  - VLINK="#000080"
  - ALINK="#FF0000"
  ->
  -<!--#include virtual="header.html" -->
  -<H1 ALIGN="CENTER">An In-Depth Discussion of Virtual Host Matching</H1>
  -
  -<P>The virtual host code was completely rewritten in
  -<STRONG>Apache 1.3</STRONG>.
  -This document attempts to explain exactly what Apache does when
  -deciding what virtual host to serve a hit from. With the help of the
  -new <A HREF="../mod/core.html#namevirtualhost"><SAMP>NameVirtualHost</SAMP></A>
  -directive  virtual host configuration should be a lot easier and safer
  -than with versions prior to 1.3.
  -
  -<P>If you just want to <CITE>make it work</CITE> without understanding
  -how, here are <A HREF="examples.html">some examples</A>.
  -
  -<H3>Config File Parsing</H3>
  -
  -<P>There is a <EM>main_server</EM> which consists of all
  -the definitions appearing outside of <CODE>&lt;VirtualHost&gt;</CODE> sections.
  -There are virtual servers, called <EM>vhosts</EM>, which are defined by
  -<A HREF="../mod/core.html#virtualhost"><SAMP>&lt;VirtualHost&gt;</SAMP></A>
  -sections.
  -
  -<P>The directives
  -<A HREF="../mod/core.html#port"><SAMP>Port</SAMP></A>,
  -<A HREF="../mod/core.html#servername"><SAMP>ServerName</SAMP></A>,
  -<A HREF="../mod/core.html#serverpath"><SAMP>ServerPath</SAMP></A>,
  -and
  -<A HREF="../mod/core.html#serveralias"><SAMP>ServerAlias</SAMP></A>
  -can appear anywhere within the definition of
  -a server.  However, each appearance overrides the previous appearance
  -(within that server).
  -
  -<P>The default value of the <CODE>Port</CODE> field for main_server
  -is 80.  The main_server has no default <CODE>ServerPath</CODE>, or
  -<CODE>ServerAlias</CODE>. The default <CODE>ServerName</CODE> is
  -deduced from the servers IP address.
  -
  -<P>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
  -<A HREF="../mod/core.html#listen"><CODE>Listen</CODE></A> directives.
  -The second function is to specify the port number which is used
  -in absolute URIs during redirects.
  -
  -<P>Unlike the main_server, vhost ports <EM>do not</EM> affect what
  -ports Apache listens for connections on.
  -
  -<P>Each address appearing in the <CODE>VirtualHost</CODE> directive
  -can have an optional port.  If the port is unspecified it defaults to
  -the value of the main_server's most recent <CODE>Port</CODE> statement.
  -The special port <SAMP>*</SAMP> indicates a wildcard that matches any port.
  -Collectively the entire set of addresses (including multiple
  -<SAMP>A</SAMP> record
  -results from DNS lookups) are called the vhost's <EM>address set</EM>.
  -
  -<P>Unless a <A HREF="../mod/core.html#namevirtualhost">NameVirtualHost</A>
  -directive is used for a specific IP address the first vhost with
  -that address is treated as an IP-based vhost. The IP address can also
  -be the wildcard <CODE>*</CODE>.
  -
  -<P>If name-based vhosts should be used a <CODE>NameVirtualHost</CODE>
  -directive <EM>must</EM> appear with the IP address set to be used for the
  -name-based vhosts. In other words, you must specify the IP address that
  -holds the hostname aliases (CNAMEs) for your name-based vhosts via a
  -<CODE>NameVirtualHost</CODE> directive in your configuration file.
  -
  -<P>Multiple <CODE>NameVirtualHost</CODE> directives can be used each
  -with a set of <CODE>VirtualHost</CODE> directives but only one
  -<CODE>NameVirtualHost</CODE> directive should be used for each
  -specific IP:port pair.
  -
  -<P>The ordering of <CODE>NameVirtualHost</CODE> and 
  -<CODE>VirtualHost</CODE> directives is not important which makes the
  -following two examples identical (only the order of the
  -<CODE>VirtualHost</CODE> directives for <EM>one</EM> address set
  -is important, see below):
  +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  +    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   
  -<PRE>
  +<html xmlns="http://www.w3.org/1999/xhtml">
  +  <head>
  +    <meta name="generator" content="HTML Tidy, see www.w3.org" />
  +
  +    <title>An In-Depth Discussion of Virtual Host Matching</title>
  +  </head>
  +  <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  +
  +  <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
  +  vlink="#000080" alink="#FF0000">
  +    <!--#include virtual="header.html" -->
  +
  +    <h1 align="CENTER">An In-Depth Discussion of Virtual Host
  +    Matching</h1>
  +
  +    <p>The virtual host code was completely rewritten in
  +    <strong>Apache 1.3</strong>. This document attempts to explain
  +    exactly what Apache does when deciding what virtual host to
  +    serve a hit from. With the help of the new <a
  +    href="../mod/core.html#namevirtualhost"><samp>NameVirtualHost</samp></a>
  +    directive virtual host configuration should be a lot easier and
  +    safer than with versions prior to 1.3.</p>
  +
  +    <p>If you just want to <cite>make it work</cite> without
  +    understanding how, here are <a href="examples.html">some
  +    examples</a>.</p>
  +
  +    <h3>Config File Parsing</h3>
  +
  +    <p>There is a <em>main_server</em> which consists of all the
  +    definitions appearing outside of
  +    <code>&lt;VirtualHost&gt;</code> sections. There are virtual
  +    servers, called <em>vhosts</em>, which are defined by <a
  +    href="../mod/core.html#virtualhost"><samp>&lt;VirtualHost&gt;</samp></a>
  +    sections.</p>
  +
  +    <p>The directives <a
  +    href="../mod/core.html#port"><samp>Port</samp></a>, <a
  +    href="../mod/core.html#servername"><samp>ServerName</samp></a>,
  +    <a
  +    href="../mod/core.html#serverpath"><samp>ServerPath</samp></a>,
  +    and <a
  +    href="../mod/core.html#serveralias"><samp>ServerAlias</samp></a>
  +    can appear anywhere within the definition of a server. However,
  +    each appearance overrides the previous appearance (within that
  +    server).</p>
  +
  +    <p>The default value of the <code>Port</code> field for
  +    main_server is 80. The main_server has no default
  +    <code>ServerPath</code>, or <code>ServerAlias</code>. The
  +    default <code>ServerName</code> is deduced from the servers IP
  +    address.</p>
  +
  +    <p>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 <a
  +    href="../mod/core.html#listen"><code>Listen</code></a>
  +    directives. The second function is to specify the port number
  +    which is used in absolute URIs during redirects.</p>
  +
  +    <p>Unlike the main_server, vhost ports <em>do not</em> affect
  +    what ports Apache listens for connections on.</p>
  +
  +    <p>Each address appearing in the <code>VirtualHost</code>
  +    directive can have an optional port. If the port is unspecified
  +    it defaults to the value of the main_server's most recent
  +    <code>Port</code> statement. The special port <samp>*</samp>
  +    indicates a wildcard that matches any port. Collectively the
  +    entire set of addresses (including multiple <samp>A</samp>
  +    record results from DNS lookups) are called the vhost's
  +    <em>address set</em>.</p>
  +
  +    <p>Unless a <a
  +    href="../mod/core.html#namevirtualhost">NameVirtualHost</a>
  +    directive is used for a specific IP address the first vhost
  +    with that address is treated as an IP-based vhost. The IP
  +    address can also be the wildcard <code>*</code>.</p>
  +
  +    <p>If name-based vhosts should be used a
  +    <code>NameVirtualHost</code> directive <em>must</em> appear
  +    with the IP address set to be used for the name-based vhosts.
  +    In other words, you must specify the IP address that holds the
  +    hostname aliases (CNAMEs) for your name-based vhosts via a
  +    <code>NameVirtualHost</code> directive in your configuration
  +    file.</p>
  +
  +    <p>Multiple <code>NameVirtualHost</code> directives can be used
  +    each with a set of <code>VirtualHost</code> directives but only
  +    one <code>NameVirtualHost</code> directive should be used for
  +    each specific IP:port pair.</p>
  +
  +    <p>The ordering of <code>NameVirtualHost</code> and
  +    <code>VirtualHost</code> directives is not important which
  +    makes the following two examples identical (only the order of
  +    the <code>VirtualHost</code> directives for <em>one</em>
  +    address set is important, see below):</p>
  +<pre>
                                   |
     NameVirtualHost 111.22.33.44  | &lt;VirtualHost 111.22.33.44&gt;
     &lt;VirtualHost 111.22.33.44&gt;    | # server A
  -  # server A  		        | &lt;/VirtualHost&gt;
  -  ... 			        | &lt;VirtualHost 111.22.33.55&gt;
  -  &lt;/VirtualHost&gt;	        | # server C
  +  # server A                | &lt;/VirtualHost&gt;
  +  ...                   | &lt;VirtualHost 111.22.33.55&gt;
  +  &lt;/VirtualHost&gt;          | # server C
     &lt;VirtualHost 111.22.33.44&gt;    | ...
  -  # server B  		        | &lt;/VirtualHost&gt;
  -  ... 			        | &lt;VirtualHost 111.22.33.44&gt;
  -  &lt;/VirtualHost&gt;	        | # server B
  +  # server B                | &lt;/VirtualHost&gt;
  +  ...                   | &lt;VirtualHost 111.22.33.44&gt;
  +  &lt;/VirtualHost&gt;          | # server B
                                   | ...
     NameVirtualHost 111.22.33.55  | &lt;/VirtualHost&gt;
     &lt;VirtualHost 111.22.33.55&gt;    | &lt;VirtualHost 111.22.33.55&gt;
  -  # server C  		        | # server D
  -  ... 			        | ...
  -  &lt;/VirtualHost&gt;	        | &lt;/VirtualHost&gt;
  +  # server C                | # server D
  +  ...                   | ...
  +  &lt;/VirtualHost&gt;          | &lt;/VirtualHost&gt;
     &lt;VirtualHost 111.22.33.55&gt;    |
  -  # server D  		        | NameVirtualHost 111.22.33.44
  -  ... 			        | NameVirtualHost 111.22.33.55
  -  &lt;/VirtualHost&gt;	        |
  +  # server D                | NameVirtualHost 111.22.33.44
  +  ...                   | NameVirtualHost 111.22.33.55
  +  &lt;/VirtualHost&gt;          |
                                   |
  -</PRE>
  +</pre>
   
  -<P>(To aid the readability of your configuration you should prefer the
  -left variant.)
  +    <p>(To aid the readability of your configuration you should
  +    prefer the left variant.)</p>
   
  -<P> After parsing the <CODE>VirtualHost</CODE> directive, the vhost server
  -is given a default <CODE>Port</CODE> equal to the port assigned to the
  -first name in its <CODE>VirtualHost</CODE> directive.
  -
  -<P>The complete list of names in the <CODE>VirtualHost</CODE> directive
  -are treated just like a <CODE>ServerAlias</CODE> (but are not overridden by any
  -<CODE>ServerAlias</CODE> statement) if all names resolve to the same address
  -set.  Note that subsequent <CODE>Port</CODE> statements for this vhost will not
  -affect the ports assigned in the address set.
  -
  -<P>During initialization a list for each IP address
  -is generated and inserted into an hash table. If the IP address is
  -used in a <CODE>NameVirtualHost</CODE> directive the list contains
  -all name-based vhosts for the given IP address. If there are no
  -vhosts defined for that address the <CODE>NameVirtualHost</CODE> directive
  -is ignored and an error is logged. For an IP-based vhost the list in the
  -hash table is empty.
  -
  -<P>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 addresses which vary in the last octet.
  -
  -<P>For every vhost various default values are set. In particular:
  -
  -<OL>
  -<LI>If a vhost has no
  -    <A HREF="../mod/core.html#serveradmin"><CODE>ServerAdmin</CODE></A>,
  -    <A HREF="../mod/core.html#resourceconfig"><CODE>ResourceConfig</CODE></A>,
  -    <A HREF="../mod/core.html#accessconfig"><CODE>AccessConfig</CODE></A>,
  -    <A HREF="../mod/core.html#timeout"><CODE>Timeout</CODE></A>,
  -    <A HREF="../mod/core.html#keepalivetimeout"
  -    ><CODE>KeepAliveTimeout</CODE></A>,
  -    <A HREF="../mod/core.html#keepalive"><CODE>KeepAlive</CODE></A>,
  -    <A HREF="../mod/core.html#maxkeepaliverequests"
  -    ><CODE>MaxKeepAliveRequests</CODE></A>,
  -    or
  -    <A HREF="../mod/core.html#sendbuffersize"><CODE>SendBufferSize</CODE></A>
  -    directive then the respective value is
  -    inherited from the main_server.  (That is, inherited from whatever
  -    the final setting of that value is in the main_server.)
  -
  -<LI>The &quot;lookup defaults&quot; that define the default directory
  -    permissions
  -    for a vhost are merged with those of the main_server.  This includes
  -    any per-directory configuration information for any module.
  -
  -<LI>The per-server configs for each module from the main_server are
  -    merged into the vhost server.
  -</OL>
  -
  -Essentially, the main_server is treated as &quot;defaults&quot; or a
  -&quot;base&quot; on which to build each vhost.
  -But the positioning of these main_server
  -definitions in the config file is largely irrelevant -- the entire
  -config of the main_server has been parsed when this final merging occurs.
  -So even if a main_server definition appears after a vhost definition
  -it might affect the vhost definition.
  -
  -<P> If the main_server has no <CODE>ServerName</CODE> at this point,
  -then the hostname of the machine that httpd is running on is used
  -instead.  We will call the <EM>main_server address set</EM> those IP
  -addresses returned by a DNS lookup on the <CODE>ServerName</CODE> of
  -the main_server.
  -
  -<P> For any undefined <CODE>ServerName</CODE> fields, a name-based vhost
  -defaults to the address given first in the <CODE>VirtualHost</CODE>
  -statement defining the vhost.
  -
  -<P>Any vhost that includes the magic <SAMP>_default_</SAMP> wildcard
  -is given the same <CODE>ServerName</CODE> as the main_server.
  -
  -
  -<H3>Virtual Host Matching</H3>
  -
  -<P>The server determines which vhost to use for a request as follows:
  -
  -<H4>Hash table lookup</H4>
  -
  -<P>When the connection is first made by a client, the IP address to
  -which the client connected is looked up in the internal IP hash table.
  -
  -<P>If the lookup fails (the IP address wasn't found) the request is
  -served from the <SAMP>_default_</SAMP> vhost if there is such a vhost
  -for the port to which the client sent the request. If there is no
  -matching <SAMP>_default_</SAMP> vhost the request is served from the
  -main_server.
  -
  -<P>If the IP address is not found in the hash table then the match
  -against the port number may also result in an entry corresponding to a
  -<CODE>NameVirtualHost *</CODE>, which is subsequently handled like
  -other name-based vhosts.
  -
  -<P>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.
  -
  -<H4>IP-based vhost</H4>
  -
  -<P>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.
  -
  -<H4>Name-based vhost</H4>
  -
  -<P>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 <CODE>VirtualHost</CODE> directives appear in the config
  -file.
  -
  -<P>The first vhost on this list (the first vhost in the config file with
  -the specified IP address) has the highest priority and catches any request
  -to an unknown server name or a request without a <CODE>Host:</CODE>
  -header field.
  -
  -<P>If the client provided a <CODE>Host:</CODE> header field the list is
  -searched for a matching vhost and the first hit on a <CODE>ServerName</CODE>
  -or <CODE>ServerAlias</CODE> is taken and the request is served from
  -that vhost. A <CODE>Host:</CODE> header field can contain a port number, but
  -Apache always matches against the real port to which the client sent
  -the request.
  -
  -<P>If the client submitted a HTTP/1.0 request without <CODE>Host:</CODE>
  -header field we don't know to what server the client tried to connect and
  -any existing <CODE>ServerPath</CODE> 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.
  -
  -<P>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).
  -
  -<H4>Persistent connections</H4>
  -The IP lookup described above is only done <EM>once</EM> for a particular
  -TCP/IP session while the name lookup is done on <EM>every</EM> request
  -during a KeepAlive/persistent connection. In other words a client may
  -request pages from different name-based vhosts during a single
  -persistent connection.
  -
  -
  -<H4>Absolute URI</H4>
  -
  -<P>If the URI from the request is an absolute URI, and its hostname and
  -port match the main server or one of the configured virtual hosts
  -<EM>and</EM> match the address and port to which the client sent the request,
  -then the scheme/hostname/port prefix is stripped off and the remaining
  -relative URI is served by the corresponding main server or virtual host.
  -If it does not match, then the URI remains untouched and the request is
  -taken to be a proxy request.
  -
  -
  -<H3>Observations</H3>
  -
  -<UL>
  -
  -<LI>A name-based vhost can never interfere with an IP-base vhost and
  -    vice versa. IP-based vhosts can only be reached through an IP address
  -    of its own address set and never through any other address.
  -    The same applies to name-based vhosts, they can only be reached
  -    through an IP address of the corresponding address set which must
  -    be defined with a <CODE>NameVirtualHost</CODE> directive.
  -    <P>
  -
  -<LI><CODE>ServerAlias</CODE> and <CODE>ServerPath</CODE> checks are never
  -    performed for an IP-based vhost.
  -    <P>
  -    
  -<LI>The order of name-/IP-based, the <SAMP>_default_</SAMP>
  -    vhost and the <CODE>NameVirtualHost</CODE> directive within the config
  -    file is not important. Only the ordering
  -    of name-based vhosts for a specific address set is significant. The one
  -    name-based vhosts that comes first in the configuration file has
  -    the highest priority for its corresponding address set.
  -    <P>
  -
  -<LI>For security reasons the port number given in a <CODE>Host:</CODE>
  -    header field is never used during the matching process. Apache always
  -    uses the real port to which the client sent the request.
  -    <P>
  -
  -<LI>If a <CODE>ServerPath</CODE> directive exists which is a prefix of
  -    another <CODE>ServerPath</CODE> directive that appears later in
  -    the configuration file, then the former will always be matched
  -    and the latter will never be matched.  (That is assuming that no
  -    <CODE>Host:</CODE> header field was available to disambiguate the two.)
  -    <P>
  -
  -<LI>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. The server will give a warning in the error
  -    logfile when it detects this.
  -    <P>
  -    
  -<LI>A <CODE>_default_</CODE> vhost catches a request only if there is no
  -    other vhost with a matching IP address <EM>and</EM> a matching port
  -    number for the request. The request is only caught if the port number
  -    to which the client sent the request matches the port number of your
  -    <CODE>_default_</CODE> vhost which is your standard <CODE>Port</CODE>
  -    by default. A wildcard port can be specified (<EM>i.e.</EM>,
  -    <CODE>_default_:*</CODE>) to catch requests to any available port.
  -    This also applies to <CODE>NameVirtualHost *</CODE> vhosts.
  -    <P>
  -    
  -<LI>The main_server is only used to serve a request if the IP address
  -    and port number to which the client connected is unspecified
  -    and does not match any other vhost (including a <CODE>_default_</CODE>
  -    vhost). In other words the main_server only catches a request for an
  -    unspecified address/port combination (unless there is a
  -    <CODE>_default_</CODE> vhost which matches that port).
  -    <P>
  -    
  -<LI>A <CODE>_default_</CODE> vhost or the main_server is <EM>never</EM>
  -    matched for a request with an unknown or missing <CODE>Host:</CODE> header
  -    field if the client connected to an address (and port) which is used
  -    for name-based vhosts, <EM>e.g.</EM>, in a <CODE>NameVirtualHost</CODE>
  -    directive.
  -    <P>
  -    
  -<LI>You should never specify DNS names in <CODE>VirtualHost</CODE>
  -    directives because it will force your server to rely on DNS to boot.
  -    Furthermore it poses a security threat if you do not control the
  -    DNS for all the domains listed.
  -    There's <A HREF="../dns-caveats.html">more information</A>
  -    available on this and the next two topics.
  -    <P>
  -
  -<LI><CODE>ServerName</CODE> should always be set for each vhost.  Otherwise
  -    A DNS lookup is required for each vhost.
  -    <P>
  -
  -</UL>
  -
  -<H3>Tips</H3>
  -
  -<P>In addition to the tips on the <A HREF="../dns-caveats.html#tips">DNS
  -Issues</A> page, here are some further tips:
  -
  -<UL>
  -
  -<LI>Place all main_server definitions before any <CODE>VirtualHost</CODE>
  -    definitions. (This is to aid the readability of the configuration --
  -    the post-config merging process makes it non-obvious that definitions 
  -    mixed in around virtual hosts might affect all virtual hosts.)
  -    <P>
  -
  -<LI>Group corresponding <CODE>NameVirtualHost</CODE> and
  -    <CODE>VirtualHost</CODE> definitions in your configuration to ensure
  -    better readability.
  -    <P>
  -
  -<LI>Avoid <CODE>ServerPaths</CODE> which are prefixes of other
  -    <CODE>ServerPaths</CODE>.  If you cannot avoid this then you have to
  -    ensure that the longer (more specific) prefix vhost appears earlier in
  -    the configuration file than the shorter (less specific) prefix
  -    (<EM>i.e.</EM>, &quot;ServerPath /abc&quot; should appear after
  -    &quot;ServerPath /abc/def&quot;).
  -    <P>
  -
  -</UL>
  -
  -<!--#include virtual="footer.html" -->
  -</BODY>
  -</HTML>
  +    <p>After parsing the <code>VirtualHost</code> directive, the
  +    vhost server is given a default <code>Port</code> equal to the
  +    port assigned to the first name in its <code>VirtualHost</code>
  +    directive.</p>
  +
  +    <p>The complete list of names in the <code>VirtualHost</code>
  +    directive are treated just like a <code>ServerAlias</code> (but
  +    are not overridden by any <code>ServerAlias</code> statement)
  +    if all names resolve to the same address set. Note that
  +    subsequent <code>Port</code> statements for this vhost will not
  +    affect the ports assigned in the address set.</p>
  +
  +    <p>During initialization a list for each IP address is
  +    generated and inserted into an hash table. If the IP address is
  +    used in a <code>NameVirtualHost</code> directive the list
  +    contains all name-based vhosts for the given IP address. If
  +    there are no vhosts defined for that address the
  +    <code>NameVirtualHost</code> directive is ignored and an error
  +    is logged. For an IP-based vhost the list in the hash table is
  +    empty.</p>
  +
  +    <p>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 addresses which vary
  +    in the last octet.</p>
  +
  +    <p>For every vhost various default values are set. In
  +    particular:</p>
  +
  +    <ol>
  +      <li>If a vhost has no <a
  +      href="../mod/core.html#serveradmin"><code>ServerAdmin</code></a>,
  +      <a
  +      href="../mod/core.html#resourceconfig"><code>ResourceConfig</code></a>,
  +      <a
  +      href="../mod/core.html#accessconfig"><code>AccessConfig</code></a>,
  +      <a href="../mod/core.html#timeout"><code>Timeout</code></a>,
  +      <a
  +      href="../mod/core.html#keepalivetimeout"><code>KeepAliveTimeout</code></a>,
  +      <a
  +      href="../mod/core.html#keepalive"><code>KeepAlive</code></a>,
  +      <a
  +      href="../mod/core.html#maxkeepaliverequests"><code>MaxKeepAliveRequests</code></a>,
  +      or <a
  +      href="../mod/core.html#sendbuffersize"><code>SendBufferSize</code></a>
  +      directive then the respective value is inherited from the
  +      main_server. (That is, inherited from whatever the final
  +      setting of that value is in the main_server.)</li>
  +
  +      <li>The "lookup defaults" that define the default directory
  +      permissions for a vhost are merged with those of the
  +      main_server. This includes any per-directory configuration
  +      information for any module.</li>
  +
  +      <li>The per-server configs for each module from the
  +      main_server are merged into the vhost server.</li>
  +    </ol>
  +    Essentially, the main_server is treated as "defaults" or a
  +    "base" on which to build each vhost. But the positioning of
  +    these main_server definitions in the config file is largely
  +    irrelevant -- the entire config of the main_server has been
  +    parsed when this final merging occurs. So even if a main_server
  +    definition appears after a vhost definition it might affect the
  +    vhost definition. 
  +
  +    <p>If the main_server has no <code>ServerName</code> at this
  +    point, then the hostname of the machine that httpd is running
  +    on is used instead. We will call the <em>main_server address
  +    set</em> those IP addresses returned by a DNS lookup on the
  +    <code>ServerName</code> of the main_server.</p>
  +
  +    <p>For any undefined <code>ServerName</code> fields, a
  +    name-based vhost defaults to the address given first in the
  +    <code>VirtualHost</code> statement defining the vhost.</p>
  +
  +    <p>Any vhost that includes the magic <samp>_default_</samp>
  +    wildcard is given the same <code>ServerName</code> as the
  +    main_server.</p>
  +
  +    <h3>Virtual Host Matching</h3>
  +
  +    <p>The server determines which vhost to use for a request as
  +    follows:</p>
  +
  +    <h4>Hash table lookup</h4>
  +
  +    <p>When the connection is first made by a client, the IP
  +    address to which the client connected is looked up in the
  +    internal IP hash table.</p>
  +
  +    <p>If the lookup fails (the IP address wasn't found) the
  +    request is served from the <samp>_default_</samp> vhost if
  +    there is such a vhost for the port to which the client sent the
  +    request. If there is no matching <samp>_default_</samp> vhost
  +    the request is served from the main_server.</p>
  +
  +    <p>If the IP address is not found in the hash table then the
  +    match against the port number may also result in an entry
  +    corresponding to a <code>NameVirtualHost *</code>, which is
  +    subsequently handled like other name-based vhosts.</p>
  +
  +    <p>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.</p>
  +
  +    <h4>IP-based vhost</h4>
  +
  +    <p>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.</p>
  +
  +    <h4>Name-based vhost</h4>
  +
  +    <p>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 <code>VirtualHost</code>
  +    directives appear in the config file.</p>
  +
  +    <p>The first vhost on this list (the first vhost in the config
  +    file with the specified IP address) has the highest priority
  +    and catches any request to an unknown server name or a request
  +    without a <code>Host:</code> header field.</p>
  +
  +    <p>If the client provided a <code>Host:</code> header field the
  +    list is searched for a matching vhost and the first hit on a
  +    <code>ServerName</code> or <code>ServerAlias</code> is taken
  +    and the request is served from that vhost. A <code>Host:</code>
  +    header field can contain a port number, but Apache always
  +    matches against the real port to which the client sent the
  +    request.</p>
  +
  +    <p>If the client submitted a HTTP/1.0 request without
  +    <code>Host:</code> header field we don't know to what server
  +    the client tried to connect and any existing
  +    <code>ServerPath</code> 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.</p>
  +
  +    <p>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).</p>
  +
  +    <h4>Persistent connections</h4>
  +    The IP lookup described above is only done <em>once</em> for a
  +    particular TCP/IP session while the name lookup is done on
  +    <em>every</em> request during a KeepAlive/persistent
  +    connection. In other words a client may request pages from
  +    different name-based vhosts during a single persistent
  +    connection. 
  +
  +    <h4>Absolute URI</h4>
  +
  +    <p>If the URI from the request is an absolute URI, and its
  +    hostname and port match the main server or one of the
  +    configured virtual hosts <em>and</em> match the address and
  +    port to which the client sent the request, then the
  +    scheme/hostname/port prefix is stripped off and the remaining
  +    relative URI is served by the corresponding main server or
  +    virtual host. If it does not match, then the URI remains
  +    untouched and the request is taken to be a proxy request.</p>
  +
  +    <h3>Observations</h3>
  +
  +    <ul>
  +      <li>A name-based vhost can never interfere with an IP-base
  +      vhost and vice versa. IP-based vhosts can only be reached
  +      through an IP address of its own address set and never
  +      through any other address. The same applies to name-based
  +      vhosts, they can only be reached through an IP address of the
  +      corresponding address set which must be defined with a
  +      <code>NameVirtualHost</code> directive.</li>
  +
  +      <li><code>ServerAlias</code> and <code>ServerPath</code>
  +      checks are never performed for an IP-based vhost.</li>
  +
  +      <li>The order of name-/IP-based, the <samp>_default_</samp>
  +      vhost and the <code>NameVirtualHost</code> directive within
  +      the config file is not important. Only the ordering of
  +      name-based vhosts for a specific address set is significant.
  +      The one name-based vhosts that comes first in the
  +      configuration file has the highest priority for its
  +      corresponding address set.</li>
  +
  +      <li>For security reasons the port number given in a
  +      <code>Host:</code> header field is never used during the
  +      matching process. Apache always uses the real port to which
  +      the client sent the request.</li>
  +
  +      <li>If a <code>ServerPath</code> directive exists which is a
  +      prefix of another <code>ServerPath</code> directive that
  +      appears later in the configuration file, then the former will
  +      always be matched and the latter will never be matched. (That
  +      is assuming that no <code>Host:</code> header field was
  +      available to disambiguate the two.)</li>
  +
  +      <li>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. The server will give
  +      a warning in the error logfile when it detects this.</li>
  +
  +      <li>A <code>_default_</code> vhost catches a request only if
  +      there is no other vhost with a matching IP address
  +      <em>and</em> a matching port number for the request. The
  +      request is only caught if the port number to which the client
  +      sent the request matches the port number of your
  +      <code>_default_</code> vhost which is your standard
  +      <code>Port</code> by default. A wildcard port can be
  +      specified (<em>i.e.</em>, <code>_default_:*</code>) to catch
  +      requests to any available port. This also applies to
  +      <code>NameVirtualHost *</code> vhosts.</li>
  +
  +      <li>The main_server is only used to serve a request if the IP
  +      address and port number to which the client connected is
  +      unspecified and does not match any other vhost (including a
  +      <code>_default_</code> vhost). In other words the main_server
  +      only catches a request for an unspecified address/port
  +      combination (unless there is a <code>_default_</code> vhost
  +      which matches that port).</li>
  +
  +      <li>A <code>_default_</code> vhost or the main_server is
  +      <em>never</em> matched for a request with an unknown or
  +      missing <code>Host:</code> header field if the client
  +      connected to an address (and port) which is used for
  +      name-based vhosts, <em>e.g.</em>, in a
  +      <code>NameVirtualHost</code> directive.</li>
  +
  +      <li>You should never specify DNS names in
  +      <code>VirtualHost</code> directives because it will force
  +      your server to rely on DNS to boot. Furthermore it poses a
  +      security threat if you do not control the DNS for all the
  +      domains listed. There's <a href="../dns-caveats.html">more
  +      information</a> available on this and the next two
  +      topics.</li>
  +
  +      <li><code>ServerName</code> should always be set for each
  +      vhost. Otherwise A DNS lookup is required for each
  +      vhost.</li>
  +    </ul>
  +
  +    <h3>Tips</h3>
  +
  +    <p>In addition to the tips on the <a
  +    href="../dns-caveats.html#tips">DNS Issues</a> page, here are
  +    some further tips:</p>
  +
  +    <ul>
  +      <li>Place all main_server definitions before any
  +      <code>VirtualHost</code> definitions. (This is to aid the
  +      readability of the configuration -- the post-config merging
  +      process makes it non-obvious that definitions mixed in around
  +      virtual hosts might affect all virtual hosts.)</li>
  +
  +      <li>Group corresponding <code>NameVirtualHost</code> and
  +      <code>VirtualHost</code> definitions in your configuration to
  +      ensure better readability.</li>
  +
  +      <li>Avoid <code>ServerPaths</code> which are prefixes of
  +      other <code>ServerPaths</code>. If you cannot avoid this then
  +      you have to ensure that the longer (more specific) prefix
  +      vhost appears earlier in the configuration file than the
  +      shorter (less specific) prefix (<em>i.e.</em>, "ServerPath
  +      /abc" should appear after "ServerPath /abc/def").</li>
  +    </ul>
  +    <!--#include virtual="footer.html" -->
  +  </body>
  +</html>
  +
  
  
  
  1.4       +71 -57    httpd-2.0/docs/manual/vhosts/fd-limits.html
  
  Index: fd-limits.html
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/vhosts/fd-limits.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- fd-limits.html	1998/02/05 20:05:15	1.3
  +++ fd-limits.html	2001/09/22 19:39:26	1.4
  @@ -1,59 +1,73 @@
  -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
  -<HTML>
  -<HEAD>
  -<TITLE>Apache Server Virtual Host Support</TITLE>
  -</HEAD>
  -
  -<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  -<BODY
  - BGCOLOR="#FFFFFF"
  - TEXT="#000000"
  - LINK="#0000FF"
  - VLINK="#000080"
  - ALINK="#FF0000"
  ->
  -<!--#include virtual="header.html" -->
  -<H1 ALIGN="CENTER">File Descriptor Limits</H1>
  -
  -<P>
  -When using a large number of Virtual Hosts, Apache may run out of available
  -file descriptors (sometimes called <CITE>file handles</CITE> if each Virtual
  -Host specifies different log files.
  -The total number of file descriptors used by Apache is one for each distinct
  -error log file, one for every other log file directive, plus 10-20 for
  -internal use. Unix operating systems limit the number of file descriptors that
  -may be used by a process; the limit is typically 64, and may usually be
  -increased up to a large hard-limit.
  -<P>
  -Although Apache attempts to increase the limit as required, this
  -may not work if:
  -<OL>
  -<LI>Your system does not provide the setrlimit() system call.
  -<LI>The setrlimit(RLIMIT_NOFILE) call does not function on your system
  - (such as Solaris 2.3)
  -<LI>The number of file descriptors required exceeds the hard limit.
  -<LI>Your system imposes other limits on file descriptors, such as a limit
  -on stdio streams only using file descriptors below 256. (Solaris 2)
  -</OL>
  -
  -In the event of problems you can:
  -<UL>
  -<LI>Reduce the number of log files; don't specify log files in the VirtualHost
  -sections, but only log to the main log files.
  -<LI>If you system falls into 1 or 2 (above), then increase the file descriptor
  -limit before starting Apache, using a script like
  -<BLOCKQUOTE><CODE>
  -#!/bin/sh <BR>
  -ulimit -S -n 100 <BR>
  -exec httpd</CODE></BLOCKQUOTE>
  -</UL>
  -<P>
  -Please see the
  -<A HREF="../misc/descriptors.html">Descriptors and Apache</A>
  -document containing further details about file descriptor problems and how
  -they can be solved on your operating system.
  -</P>
  +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  +    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   
  -<!--#include virtual="footer.html" -->
  -</BODY></HTML>
  +<html xmlns="http://www.w3.org/1999/xhtml">
  +  <head>
  +    <meta name="generator" content="HTML Tidy, see www.w3.org" />
  +
  +    <title>Apache Server Virtual Host Support</title>
  +  </head>
  +  <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  +
  +  <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
  +  vlink="#000080" alink="#FF0000">
  +    <!--#include virtual="header.html" -->
  +
  +    <h1 align="CENTER">File Descriptor Limits</h1>
  +
  +    <p>When using a large number of Virtual Hosts, Apache may run
  +    out of available file descriptors (sometimes called <cite>file
  +    handles</cite> if each Virtual Host specifies different log
  +    files. The total number of file descriptors used by Apache is
  +    one for each distinct error log file, one for every other log
  +    file directive, plus 10-20 for internal use. Unix operating
  +    systems limit the number of file descriptors that may be used
  +    by a process; the limit is typically 64, and may usually be
  +    increased up to a large hard-limit.</p>
  +
  +    <p>Although Apache attempts to increase the limit as required,
  +    this may not work if:</p>
  +
  +    <ol>
  +      <li>Your system does not provide the setrlimit() system
  +      call.</li>
  +
  +      <li>The setrlimit(RLIMIT_NOFILE) call does not function on
  +      your system (such as Solaris 2.3)</li>
  +
  +      <li>The number of file descriptors required exceeds the hard
  +      limit.</li>
  +
  +      <li>Your system imposes other limits on file descriptors,
  +      such as a limit on stdio streams only using file descriptors
  +      below 256. (Solaris 2)</li>
  +    </ol>
  +    In the event of problems you can: 
  +
  +    <ul>
  +      <li>Reduce the number of log files; don't specify log files
  +      in the VirtualHost sections, but only log to the main log
  +      files.</li>
  +
  +      <li>
  +        If you system falls into 1 or 2 (above), then increase the
  +        file descriptor limit before starting Apache, using a
  +        script like 
  +
  +        <blockquote>
  +          <code>#!/bin/sh<br />
  +           ulimit -S -n 100<br />
  +           exec httpd</code>
  +        </blockquote>
  +      </li>
  +    </ul>
  +
  +    <p>Please see the <a
  +    href="../misc/descriptors.html">Descriptors and Apache</a>
  +    document containing further details about file descriptor
  +    problems and how they can be solved on your operating
  +    system.</p>
  +    <!--#include virtual="footer.html" -->
  +  </body>
  +</html>
   
  
  
  
  1.5       +17 -6     httpd-2.0/docs/manual/vhosts/footer.html
  
  Index: footer.html
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/vhosts/footer.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- footer.html	2000/12/21 05:16:17	1.4
  +++ footer.html	2001/09/22 19:39:26	1.5
  @@ -1,8 +1,19 @@
  -<HR>
  +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  +    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   
  -<H3 ALIGN="CENTER">
  - Apache HTTP Server Version 2.0 
  -</H3>
  +<html xmlns="http://www.w3.org/1999/xhtml">
  +  <head>
  +    <meta name="generator" content="HTML Tidy, see www.w3.org" />
   
  -<A HREF="./"><IMG SRC="../images/index.gif" ALT="Index"></A>
  -<A HREF="../"><IMG SRC="../images/home.gif" ALT="Home"></A>
  +    <title></title>
  +  </head>
  +
  +  <body>
  +    <hr />
  +
  +    <h3 align="CENTER">Apache HTTP Server Version 2.0</h3>
  +    <a href="./"><img src="../images/index.gif" alt="Index" /></a>
  +    <a href="../"><img src="../images/home.gif" alt="Home" /></a>
  +  </body>
  +</html>
  +
  
  
  
  1.4       +19 -6     httpd-2.0/docs/manual/vhosts/header.html
  
  Index: header.html
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/vhosts/header.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- header.html	2000/12/21 05:16:17	1.3
  +++ header.html	2001/09/22 19:39:26	1.4
  @@ -1,6 +1,19 @@
  -<DIV ALIGN="CENTER">
  - <IMG SRC="../images/sub.gif" ALT="[APACHE DOCUMENTATION]">
  - <H3>
  -  Apache HTTP Server Version 2.0 
  - </H3>
  -</DIV>
  +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  +    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  +
  +<html xmlns="http://www.w3.org/1999/xhtml">
  +  <head>
  +    <meta name="generator" content="HTML Tidy, see www.w3.org" />
  +
  +    <title></title>
  +  </head>
  +
  +  <body>
  +    <div align="CENTER">
  +      <img src="../images/sub.gif" alt="[APACHE DOCUMENTATION]" /> 
  +
  +      <h3>Apache HTTP Server Version 2.0</h3>
  +    </div>
  +  </body>
  +</html>
  +
  
  
  
  1.8       +84 -65    httpd-2.0/docs/manual/vhosts/index.html
  
  Index: index.html
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/vhosts/index.html,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- index.html	2000/10/19 19:25:47	1.7
  +++ index.html	2001/09/22 19:39:26	1.8
  @@ -1,65 +1,84 @@
  -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
  -<HTML>
  -<HEAD>
  -<TITLE>Apache Virtual Host documentation</TITLE>
  -</HEAD>
  -
  -<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  -<BODY
  - BGCOLOR="#FFFFFF"
  - TEXT="#000000"
  - LINK="#0000FF"
  - VLINK="#000080"
  - ALINK="#FF0000"
  ->
  -<!--#include virtual="header.html" -->
  -<H1 ALIGN="CENTER">Apache Virtual Host documentation</H1>
  -
  -<P>The term <CITE>Virtual Host</CITE> refers to the practice of maintaining
  -more than one server on one machine, as differentiated by their apparent
  -hostname. For example, it is often desirable for companies sharing a
  -web server to have their own domains, with web servers accessible as
  -<SAMP>www.company1.com</SAMP> and <SAMP>www.company2.com</SAMP>,
  -without requiring the user to know any extra path information.</P>
  -
  -<P>Apache was one of the first servers to support IP-based
  -virtual hosts right out of the box. Versions 1.1 and later of
  -Apache support both, IP-based and name-based virtual hosts (vhosts).
  -The latter variant of virtual hosts is sometimes also called host-based or
  -non-IP virtual hosts.</P>
  -
  -<P>Below is a list of documentation pages which explain all details
  -of virtual host support in Apache version 1.3 and later.</P>
  -
  -<HR>
  -
  -<H2>Virtual Host Support</H2>
  -
  -<UL>
  -<LI><A HREF="name-based.html">Name-based Virtual Hosts</A>
  -<LI><A HREF="ip-based.html">IP-based Virtual Hosts</A>
  -<LI><A HREF="examples.html">Virtual Host examples for common setups</A>
  -<LI><A HREF="details.html">In-Depth Discussion of Virtual Host Matching</A>
  -<LI><A HREF="fd-limits.html">File Descriptor Limits</A>
  -<LI><A HREF="mass.html">Dynamically Configured Mass Virtual Hosting</A>
  -</UL>
  -
  -<H2>Configuration directives</H2>
  -
  -<UL>
  -<LI><A HREF="../mod/core.html#virtualhost">&lt;VirtualHost&gt;</A>
  -<LI><A HREF="../mod/core.html#namevirtualhost">NameVirtualHost</A>
  -<LI><A HREF="../mod/core.html#servername">ServerName</A>
  -<LI><A HREF="../mod/core.html#serveralias">ServerAlias</A>
  -<LI><A HREF="../mod/core.html#serverpath">ServerPath</A>
  -</UL>
  -
  -<P>Folks trying to debug their virtual host configuration may find the
  -Apache <CODE>-S</CODE> command line switch useful.  It will dump out a
  -description of how Apache parsed the configuration file.  Careful
  -examination of the IP addresses and server names may help uncover
  -configuration mistakes.
  -
  -<!--#include virtual="footer.html" -->
  -</BODY>
  -</HTML>
  +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  +    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  +
  +<html xmlns="http://www.w3.org/1999/xhtml">
  +  <head>
  +    <meta name="generator" content="HTML Tidy, see www.w3.org" />
  +
  +    <title>Apache Virtual Host documentation</title>
  +  </head>
  +  <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  +
  +  <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
  +  vlink="#000080" alink="#FF0000">
  +    <!--#include virtual="header.html" -->
  +
  +    <h1 align="CENTER">Apache Virtual Host documentation</h1>
  +
  +    <p>The term <cite>Virtual Host</cite> refers to the practice of
  +    maintaining more than one server on one machine, as
  +    differentiated by their apparent hostname. For example, it is
  +    often desirable for companies sharing a web server to have
  +    their own domains, with web servers accessible as
  +    <samp>www.company1.com</samp> and
  +    <samp>www.company2.com</samp>, without requiring the user to
  +    know any extra path information.</p>
  +
  +    <p>Apache was one of the first servers to support IP-based
  +    virtual hosts right out of the box. Versions 1.1 and later of
  +    Apache support both, IP-based and name-based virtual hosts
  +    (vhosts). The latter variant of virtual hosts is sometimes also
  +    called host-based or non-IP virtual hosts.</p>
  +
  +    <p>Below is a list of documentation pages which explain all
  +    details of virtual host support in Apache version 1.3 and
  +    later.</p>
  +    <hr />
  +
  +    <h2>Virtual Host Support</h2>
  +
  +    <ul>
  +      <li><a href="name-based.html">Name-based Virtual
  +      Hosts</a></li>
  +
  +      <li><a href="ip-based.html">IP-based Virtual Hosts</a></li>
  +
  +      <li><a href="examples.html">Virtual Host examples for common
  +      setups</a></li>
  +
  +      <li><a href="details.html">In-Depth Discussion of Virtual
  +      Host Matching</a></li>
  +
  +      <li><a href="fd-limits.html">File Descriptor Limits</a></li>
  +
  +      <li><a href="mass.html">Dynamically Configured Mass Virtual
  +      Hosting</a></li>
  +    </ul>
  +
  +    <h2>Configuration directives</h2>
  +
  +    <ul>
  +      <li><a
  +      href="../mod/core.html#virtualhost">&lt;VirtualHost&gt;</a></li>
  +
  +      <li><a
  +      href="../mod/core.html#namevirtualhost">NameVirtualHost</a></li>
  +
  +      <li><a href="../mod/core.html#servername">ServerName</a></li>
  +
  +      <li><a
  +      href="../mod/core.html#serveralias">ServerAlias</a></li>
  +
  +      <li><a href="../mod/core.html#serverpath">ServerPath</a></li>
  +    </ul>
  +
  +    <p>Folks trying to debug their virtual host configuration may
  +    find the Apache <code>-S</code> command line switch useful. It
  +    will dump out a description of how Apache parsed the
  +    configuration file. Careful examination of the IP addresses and
  +    server names may help uncover configuration mistakes. 
  +    <!--#include virtual="footer.html" -->
  +    </p>
  +  </body>
  +</html>
  +
  
  
  
  1.8       +122 -117  httpd-2.0/docs/manual/vhosts/ip-based.html
  
  Index: ip-based.html
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/vhosts/ip-based.html,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- ip-based.html	2000/09/15 19:33:53	1.7
  +++ ip-based.html	2001/09/22 19:39:26	1.8
  @@ -1,91 +1,100 @@
  -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
  -<HTML>
  -<HEAD>
  -<TITLE>Apache IP-based Virtual Host Support</TITLE>
  -</HEAD>
  -
  -<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  -<BODY
  - BGCOLOR="#FFFFFF"
  - TEXT="#000000"
  - LINK="#0000FF"
  - VLINK="#000080"
  - ALINK="#FF0000"
  ->
  -<!--#include virtual="header.html" -->
  -<H1 ALIGN="CENTER">Apache IP-based Virtual Host Support</H1>
  -
  -<STRONG>See also:</STRONG>
  -<A HREF="name-based.html">Name-based Virtual Hosts Support</A>
  -
  -<HR>
  -
  -<H2>System requirements</H2>
  -As the term <CITE>IP-based</CITE> indicates, the server <STRONG>must have a
  -different IP address for each IP-based virtual host</STRONG>.
  -This can be achieved by the machine having several physical network connections,
  -or by use of virtual interfaces which are supported by most modern
  -operating systems (see system documentation for details, these are
  -frequently called "ip aliases", and the "ifconfig" command
  -is most commonly used to set them up).
  -
  -<H2>How to set up Apache</H2>
  -There are two ways of configuring apache to support multiple hosts.
  -Either by running a separate httpd daemon for each hostname, or by running a
  -single daemon which supports all the virtual hosts.
  -<P>
  -Use multiple daemons when:
  -<UL>
  -<LI>There are security partitioning issues, such as company1 does not want
  -    anyone at company2 to be able to read their data except via the web.
  -    In this case you would need two daemons, each running with different
  -    <A HREF="../mod/core.html#user">User</A>,
  -    <A HREF="../mod/core.html#group">Group</A>,
  -    <A HREF="../mod/core.html#listen">Listen</A>, and
  -    <A HREF="../mod/core.html#serverroot">ServerRoot</A> settings.
  -<LI>You can afford the memory and
  -    <A HREF="../misc/descriptors.html">file descriptor requirements</A> of
  -    listening to every IP alias on the machine.  It's only possible to
  -    <A HREF="../mod/core.html#listen">Listen</A>
  -    to the "wildcard" address, or to specific addresses.  So if you have
  -    a need to listen to a specific address for whatever reason, then you
  -    will need to listen to all specific addresses.  (Although one httpd
  -    could listen to N-1 of the addresses, and another could listen to
  -    the remaining address.)
  -</UL>
  -Use a single daemon when:
  -<UL>
  -<LI>Sharing of the httpd configuration between virtual hosts is acceptable.
  -<LI>The machine services a large number of requests, and so the performance
  -   loss in running separate daemons may be significant.
  -</UL>
  -
  -<H2>Setting up multiple daemons</H2>
  -Create a separate httpd installation for each virtual host.
  -For each installation, use the
  -<A HREF="../mod/core.html#listen">Listen</A> directive in the configuration
  -file to select which IP address (or virtual host) that daemon services.
  -e.g.
  -<PRE>
  +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  +    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  +
  +<html xmlns="http://www.w3.org/1999/xhtml">
  +  <head>
  +    <meta name="generator" content="HTML Tidy, see www.w3.org" />
  +
  +    <title>Apache IP-based Virtual Host Support</title>
  +  </head>
  +  <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  +
  +  <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
  +  vlink="#000080" alink="#FF0000">
  +    <!--#include virtual="header.html" -->
  +
  +    <h1 align="CENTER">Apache IP-based Virtual Host Support</h1>
  +    <strong>See also:</strong> <a href="name-based.html">Name-based
  +    Virtual Hosts Support</a> 
  +    <hr />
  +
  +    <h2>System requirements</h2>
  +    As the term <cite>IP-based</cite> indicates, the server
  +    <strong>must have a different IP address for each IP-based
  +    virtual host</strong>. This can be achieved by the machine
  +    having several physical network connections, or by use of
  +    virtual interfaces which are supported by most modern operating
  +    systems (see system documentation for details, these are
  +    frequently called "ip aliases", and the "ifconfig" command is
  +    most commonly used to set them up). 
  +
  +    <h2>How to set up Apache</h2>
  +    There are two ways of configuring apache to support multiple
  +    hosts. Either by running a separate httpd daemon for each
  +    hostname, or by running a single daemon which supports all the
  +    virtual hosts. 
  +
  +    <p>Use multiple daemons when:</p>
  +
  +    <ul>
  +      <li>There are security partitioning issues, such as company1
  +      does not want anyone at company2 to be able to read their
  +      data except via the web. In this case you would need two
  +      daemons, each running with different <a
  +      href="../mod/core.html#user">User</a>, <a
  +      href="../mod/core.html#group">Group</a>, <a
  +      href="../mod/core.html#listen">Listen</a>, and <a
  +      href="../mod/core.html#serverroot">ServerRoot</a>
  +      settings.</li>
  +
  +      <li>You can afford the memory and <a
  +      href="../misc/descriptors.html">file descriptor
  +      requirements</a> of listening to every IP alias on the
  +      machine. It's only possible to <a
  +      href="../mod/core.html#listen">Listen</a> to the "wildcard"
  +      address, or to specific addresses. So if you have a need to
  +      listen to a specific address for whatever reason, then you
  +      will need to listen to all specific addresses. (Although one
  +      httpd could listen to N-1 of the addresses, and another could
  +      listen to the remaining address.)</li>
  +    </ul>
  +    Use a single daemon when: 
  +
  +    <ul>
  +      <li>Sharing of the httpd configuration between virtual hosts
  +      is acceptable.</li>
  +
  +      <li>The machine services a large number of requests, and so
  +      the performance loss in running separate daemons may be
  +      significant.</li>
  +    </ul>
  +
  +    <h2>Setting up multiple daemons</h2>
  +    Create a separate httpd installation for each virtual host. For
  +    each installation, use the <a
  +    href="../mod/core.html#listen">Listen</a> directive in the
  +    configuration file to select which IP address (or virtual host)
  +    that daemon services. e.g. 
  +<pre>
       Listen www.smallco.com:80
  -</PRE>
  -It is recommended that you use an IP address instead of a hostname
  -(see <A HREF="../dns-caveats.html">DNS caveats</A>).
  -
  -<H2>Setting up a single daemon with virtual hosts</H2>
  -For this case, a single httpd will service requests for the main server
  -and all the virtual hosts.
  -The <A HREF="../mod/core.html#virtualhost">VirtualHost</A> directive in the
  - configuration file is used to set the values of
  -<A HREF="../mod/core.html#serveradmin">ServerAdmin</A>,
  -<A HREF="../mod/core.html#servername">ServerName</A>,
  -<A HREF="../mod/core.html#documentroot">DocumentRoot</A>,
  -<A HREF="../mod/core.html#errorlog">ErrorLog</A> and
  -<A HREF="../mod/mod_log_config.html#transferlog">TransferLog</A> or
  -<A HREF="../mod/mod_log_config.html#customlog">CustomLog</A>
  -configuration directives to different values for each virtual host.
  -e.g.
  -<PRE>
  +</pre>
  +    It is recommended that you use an IP address instead of a
  +    hostname (see <a href="../dns-caveats.html">DNS caveats</a>). 
  +
  +    <h2>Setting up a single daemon with virtual hosts</h2>
  +    For this case, a single httpd will service requests for the
  +    main server and all the virtual hosts. The <a
  +    href="../mod/core.html#virtualhost">VirtualHost</a> directive
  +    in the configuration file is used to set the values of <a
  +    href="../mod/core.html#serveradmin">ServerAdmin</a>, <a
  +    href="../mod/core.html#servername">ServerName</a>, <a
  +    href="../mod/core.html#documentroot">DocumentRoot</a>, <a
  +    href="../mod/core.html#errorlog">ErrorLog</a> and <a
  +    href="../mod/mod_log_config.html#transferlog">TransferLog</a>
  +    or <a href="../mod/mod_log_config.html#customlog">CustomLog</a>
  +    configuration directives to different values for each virtual
  +    host. e.g. 
  +<pre>
       &lt;VirtualHost www.smallco.com&gt;
       ServerAdmin webmaster@mail.smallco.com
       DocumentRoot /groups/smallco/www
  @@ -101,34 +110,30 @@
       ErrorLog /groups/baygroup/logs/error_log
       TransferLog /groups/baygroup/logs/access_log
       &lt;/VirtualHost&gt;
  -</PRE>
  -
  -It is recommended that you use an IP address instead of a hostname
  -(see <A HREF="../dns-caveats.html">DNS caveats</A>).
  -
  -<P>
  -
  -Almost <STRONG>any</STRONG> configuration directive can be put in the
  -VirtualHost directive, with the exception of directives that control
  -process creation and a few other directives.  To find out if a
  -directive can be used in the VirtualHost directive, check the
  -<A HREF="../mod/directive-dict.html#Context">Context</A> using the
  -<A HREF="../mod/directives.html">directive index</A>.
  -
  -<P>
  -<A HREF="../mod/core.html#user">User</A> and
  -<A HREF="../mod/core.html#group">Group</A> may be used inside a VirtualHost
  -directive if the <A HREF="../suexec.html">suEXEC wrapper</A> is used.
  -<P>
  -
  -<EM>SECURITY:</EM> When specifying where to write log files, be aware
  -of some security risks which are present if anyone other than the
  -user that starts Apache has write access to the directory where they
  -are written.  See the <A HREF="../misc/security_tips.html">security
  -tips</A> document for details.
  -</P>
  -
  -<!--#include virtual="footer.html" -->
  -</BODY>
  -</HTML>
  +</pre>
  +    It is recommended that you use an IP address instead of a
  +    hostname (see <a href="../dns-caveats.html">DNS caveats</a>). 
  +
  +    <p>Almost <strong>any</strong> configuration directive can be
  +    put in the VirtualHost directive, with the exception of
  +    directives that control process creation and a few other
  +    directives. To find out if a directive can be used in the
  +    VirtualHost directive, check the <a
  +    href="../mod/directive-dict.html#Context">Context</a> using the
  +    <a href="../mod/directives.html">directive index</a>.</p>
  +
  +    <p><a href="../mod/core.html#user">User</a> and <a
  +    href="../mod/core.html#group">Group</a> may be used inside a
  +    VirtualHost directive if the <a href="../suexec.html">suEXEC
  +    wrapper</a> is used.</p>
  +
  +    <p><em>SECURITY:</em> When specifying where to write log files,
  +    be aware of some security risks which are present if anyone
  +    other than the user that starts Apache has write access to the
  +    directory where they are written. See the <a
  +    href="../misc/security_tips.html">security tips</a> document
  +    for details.</p>
  +    <!--#include virtual="footer.html" -->
  +  </body>
  +</html>
   
  
  
  
  1.6       +304 -267  httpd-2.0/docs/manual/vhosts/mass.html
  
  Index: mass.html
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/vhosts/mass.html,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- mass.html	2000/04/04 13:27:02	1.5
  +++ mass.html	2001/09/22 19:39:26	1.6
  @@ -1,146 +1,176 @@
  -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
  -<HTML><HEAD>
  -<TITLE>Dynamically configured mass virtual hosting</TITLE>
  -</HEAD>
  -
  -<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  -<BODY
  - BGCOLOR="#FFFFFF"
  - TEXT="#000000"
  - LINK="#0000FF"
  - VLINK="#000080"
  - ALINK="#FF0000"
  ->
  -<!--#include virtual="header.html" -->
  -<H1 ALIGN="CENTER">Dynamically configured mass virtual hosting</H1>
  -
  -<P>This document describes how to efficiently serve an arbitrary number
  -of virtual hosts with Apache 1.3. 
  -
  -<!--
  -
  -Written by Tony Finch (fanf@demon.net) (dot@dotat.at).
  -
  -Some examples were derived from Ralf S. Engleschall's document
  -	http://www.engelschall.com/pw/apache/rewriteguide/
  -
  -Some suggestions were made by Brian Behlendorf.
  -
  --->
  -
  -<H2><A NAME="contents">Contents:</A></H2>
  -
  -<UL>
  -<LI><A HREF="#motivation">Motivation</A>
  -<LI><A HREF="#overview">Overview</A>
  -<LI><A HREF="#simple">Simple dynamic virtual hosts</A>
  -<LI><A HREF="#homepages">A virtually hosted homepages system</A>
  -<LI><A HREF="#combinations">Using more than one virtual hosting system on the same server</A>
  -<LI><A HREF="#ipbased">More efficient IP-based virtual hosting</A>
  -<LI><A HREF="#oldversion">Using older versions of Apache</A>
  -<LI><A HREF="#simple.rewrite">Simple dynamic virtual hosts using <CODE>mod_rewrite</CODE></A>
  -<LI><A HREF="#homepages.rewrite">A homepages system using <CODE>mod_rewrite</CODE></A>
  -<LI><A HREF="#xtra-conf">Using a separate virtual host configuration file</A>
  -</UL>
  -
  -<HR><H2><A NAME="motivation">Motivation</A></H2>
  -
  -<P>The techniques described here are of interest if your
  -<CODE>httpd.conf</CODE> contains many
  -<CODE>&lt;VirtualHost&gt;</CODE> sections that are substantially the
  -same, for example:
  -<PRE>
  +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  +    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  +
  +<html xmlns="http://www.w3.org/1999/xhtml">
  +  <head>
  +    <meta name="generator" content="HTML Tidy, see www.w3.org" />
  +
  +    <title>Dynamically configured mass virtual hosting</title>
  +  </head>
  +  <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  +
  +  <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
  +  vlink="#000080" alink="#FF0000">
  +    <!--#include virtual="header.html" -->
  +
  +    <h1 align="CENTER">Dynamically configured mass virtual
  +    hosting</h1>
  +
  +    <p>This document describes how to efficiently serve an
  +    arbitrary number of virtual hosts with Apache 1.3. <!--
  +
  +                Written by Tony Finch (fanf@demon.net) (dot@dotat.at).
  +
  +                Some examples were derived from Ralf S. Engleschall's document
  +                    http://www.engelschall.com/pw/apache/rewriteguide/
  +
  +                Some suggestions were made by Brian Behlendorf.
  +
  +                -->
  +    </p>
  +
  +    <h2><a id="contents" name="contents">Contents:</a></h2>
  +
  +    <ul>
  +      <li><a href="#motivation">Motivation</a></li>
  +
  +      <li><a href="#overview">Overview</a></li>
  +
  +      <li><a href="#simple">Simple dynamic virtual hosts</a></li>
  +
  +      <li><a href="#homepages">A virtually hosted homepages
  +      system</a></li>
  +
  +      <li><a href="#combinations">Using more than one virtual
  +      hosting system on the same server</a></li>
  +
  +      <li><a href="#ipbased">More efficient IP-based virtual
  +      hosting</a></li>
  +
  +      <li><a href="#oldversion">Using older versions of
  +      Apache</a></li>
  +
  +      <li><a href="#simple.rewrite">Simple dynamic virtual hosts
  +      using <code>mod_rewrite</code></a></li>
  +
  +      <li><a href="#homepages.rewrite">A homepages system using
  +      <code>mod_rewrite</code></a></li>
  +
  +      <li><a href="#xtra-conf">Using a separate virtual host
  +      configuration file</a></li>
  +    </ul>
  +    <hr />
  +
  +    <h2><a id="motivation" name="motivation">Motivation</a></h2>
  +
  +    <p>The techniques described here are of interest if your
  +    <code>httpd.conf</code> contains many
  +    <code>&lt;VirtualHost&gt;</code> sections that are
  +    substantially the same, for example:</p>
  +<pre>
   NameVirtualHost 111.22.33.44
   &lt;VirtualHost 111.22.33.44&gt;
  -	ServerName		           www.customer-1.com
  -	DocumentRoot		/www/hosts/www.customer-1.com/docs
  -	ScriptAlias  /cgi-bin/  /www/hosts/www.customer-1.com/cgi-bin
  +    ServerName                 www.customer-1.com
  +    DocumentRoot        /www/hosts/www.customer-1.com/docs
  +    ScriptAlias  /cgi-bin/  /www/hosts/www.customer-1.com/cgi-bin
   &lt;/VirtualHost&gt;
   &lt;VirtualHost 111.22.33.44&gt;
  -	ServerName		           www.customer-2.com
  -	DocumentRoot		/www/hosts/www.customer-2.com/docs
  -	ScriptAlias  /cgi-bin/  /www/hosts/www.customer-2.com/cgi-bin
  +    ServerName                 www.customer-2.com
  +    DocumentRoot        /www/hosts/www.customer-2.com/docs
  +    ScriptAlias  /cgi-bin/  /www/hosts/www.customer-2.com/cgi-bin
   &lt;/VirtualHost&gt;
   # blah blah blah
   &lt;VirtualHost 111.22.33.44&gt;
  -	ServerName		           www.customer-N.com
  -	DocumentRoot		/www/hosts/www.customer-N.com/docs
  -	ScriptAlias  /cgi-bin/  /www/hosts/www.customer-N.com/cgi-bin
  +    ServerName                 www.customer-N.com
  +    DocumentRoot        /www/hosts/www.customer-N.com/docs
  +    ScriptAlias  /cgi-bin/  /www/hosts/www.customer-N.com/cgi-bin
   &lt;/VirtualHost&gt;
  -</PRE>
  -</P>
  -
  -<P>The basic idea is to replace all of the static
  -<CODE>&lt;VirtualHost&gt;</CODE> configuration with a mechanism that
  -works it out dynamically. This has a number of advantages:
  -<OL>
  -    <LI>Your configuration file is smaller so Apache starts faster and
  -	uses less memory.
  -    <LI>Adding virtual hosts is simply a matter of creating the
  -	appropriate directories in the filesystem and entries in the DNS -
  -	you don't need to reconfigure or restart Apache.
  -</OL>
  -</P>
  -
  -<P>The main disadvantage is that you cannot have a different log file
  -for each virtual host; however if you have very many virtual hosts
  -then doing this is dubious anyway because it eats file descriptors. It
  -is better to log to a pipe or a fifo and arrange for the process at
  -the other end to distribute the logs to the customers (it can also
  -accumulate statistics, etc.).</P>
  -
  -
  -<HR><H2><A NAME="overview">Overview</A></H2>
  -
  -<P>A virtual host is defined by two pieces of information: its IP
  -address, and the contents of the <CODE>Host:</CODE> header in the HTTP
  -request. The dynamic mass virtual hosting technique is based on
  -automatically inserting this information into the pathname of the file
  -that is used to satisfy the request. This is done most easily using
  -<A HREF="../mod/mod_vhost_alias.html"><CODE>mod_vhost_alias</CODE></A>,
  -but if you are using a version of Apache up to 1.3.6 then you must use
  -<A HREF="../mod/mod_rewrite.html"><CODE>mod_rewrite</CODE></A>. Both
  -of these modules are disabled by default; you must enable one of them
  -when configuring and building Apache if you want to use this technique.</P>
  -
  -<P>A couple of things need to be `faked' to make the dynamic virtual
  -host look like a normal one. The most important is the server name
  -which is used by Apache to generate self-referential URLs, etc. It
  -is configured with the <CODE>ServerName</CODE> directive, and it is
  -available to CGIs via the <CODE>SERVER_NAME</CODE> environment
  -variable. The actual value used at run time is controlled by the
  -<A HREF="../mod/core.html#usecanonicalname"><CODE>UseCanonicalName</CODE></A>
  -setting. With <CODE>UseCanonicalName Off</CODE> the server name
  -comes from the contents of the <CODE>Host:</CODE> header in the
  -request. With <CODE>UseCanonicalName DNS</CODE> it comes from a
  -reverse DNS lookup of the virtual host's IP address. The former
  -setting is used for name-based dynamic virtual hosting, and the latter
  -is used for IP-based hosting. If Apache cannot work out the server
  -name because there is no <CODE>Host:</CODE> header or the DNS lookup
  -fails then the value configured with <CODE>ServerName</CODE> is used
  -instead.</P>
  -
  -<P>The other thing to `fake' is the document root (configured
  -with <CODE>DocumentRoot</CODE> and available to CGIs via the
  -<CODE>DOCUMENT_ROOT</CODE> environment variable). In a normal
  -configuration this setting is used by the core module when mapping
  -URIs to filenames, but when the server is configured to do dynamic
  -virtual hosting that job is taken over by another module (either
  -<CODE>mod_vhost_alias</CODE> or <CODE>mod_rewrite</CODE>) which has
  -a different way of doing the mapping. Neither of these modules is
  -responsible for setting the <CODE>DOCUMENT_ROOT</CODE> environment
  -variable so if any CGIs or SSI documents make use of it they will
  -get a misleading value.</P>
  -
  -
  -<HR><H2><A NAME="simple">Simple dynamic virtual hosts</A></H2>
  -
  -<P>This extract from <CODE>httpd.conf</CODE> implements the virtual
  -host arrangement outlined in the <A HREF="#motivation">Motivation</A>
  -section above, but in a generic fashion using
  -<CODE>mod_vhost_alias</CODE>.</P>
  -
  -<PRE>
  +</pre>
  +    <br />
  +     <br />
  +     
  +
  +    <p>The basic idea is to replace all of the static
  +    <code>&lt;VirtualHost&gt;</code> configuration with a mechanism
  +    that works it out dynamically. This has a number of
  +    advantages:</p>
  +
  +    <ol>
  +      <li>Your configuration file is smaller so Apache starts
  +      faster and uses less memory.</li>
  +
  +      <li>Adding virtual hosts is simply a matter of creating the
  +      appropriate directories in the filesystem and entries in the
  +      DNS - you don't need to reconfigure or restart Apache.</li>
  +    </ol>
  +    <br />
  +     <br />
  +     
  +
  +    <p>The main disadvantage is that you cannot have a different
  +    log file for each virtual host; however if you have very many
  +    virtual hosts then doing this is dubious anyway because it eats
  +    file descriptors. It is better to log to a pipe or a fifo and
  +    arrange for the process at the other end to distribute the logs
  +    to the customers (it can also accumulate statistics, etc.).</p>
  +    <hr />
  +
  +    <h2><a id="overview" name="overview">Overview</a></h2>
  +
  +    <p>A virtual host is defined by two pieces of information: its
  +    IP address, and the contents of the <code>Host:</code> header
  +    in the HTTP request. The dynamic mass virtual hosting technique
  +    is based on automatically inserting this information into the
  +    pathname of the file that is used to satisfy the request. This
  +    is done most easily using <a
  +    href="../mod/mod_vhost_alias.html"><code>mod_vhost_alias</code></a>,
  +    but if you are using a version of Apache up to 1.3.6 then you
  +    must use <a
  +    href="../mod/mod_rewrite.html"><code>mod_rewrite</code></a>.
  +    Both of these modules are disabled by default; you must enable
  +    one of them when configuring and building Apache if you want to
  +    use this technique.</p>
  +
  +    <p>A couple of things need to be `faked' to make the dynamic
  +    virtual host look like a normal one. The most important is the
  +    server name which is used by Apache to generate
  +    self-referential URLs, etc. It is configured with the
  +    <code>ServerName</code> directive, and it is available to CGIs
  +    via the <code>SERVER_NAME</code> environment variable. The
  +    actual value used at run time is controlled by the <a
  +    href="../mod/core.html#usecanonicalname"><code>UseCanonicalName</code></a>
  +    setting. With <code>UseCanonicalName Off</code> the server name
  +    comes from the contents of the <code>Host:</code> header in the
  +    request. With <code>UseCanonicalName DNS</code> it comes from a
  +    reverse DNS lookup of the virtual host's IP address. The former
  +    setting is used for name-based dynamic virtual hosting, and the
  +    latter is used for IP-based hosting. If Apache cannot work out
  +    the server name because there is no <code>Host:</code> header
  +    or the DNS lookup fails then the value configured with
  +    <code>ServerName</code> is used instead.</p>
  +
  +    <p>The other thing to `fake' is the document root (configured
  +    with <code>DocumentRoot</code> and available to CGIs via the
  +    <code>DOCUMENT_ROOT</code> environment variable). In a normal
  +    configuration this setting is used by the core module when
  +    mapping URIs to filenames, but when the server is configured to
  +    do dynamic virtual hosting that job is taken over by another
  +    module (either <code>mod_vhost_alias</code> or
  +    <code>mod_rewrite</code>) which has a different way of doing
  +    the mapping. Neither of these modules is responsible for
  +    setting the <code>DOCUMENT_ROOT</code> environment variable so
  +    if any CGIs or SSI documents make use of it they will get a
  +    misleading value.</p>
  +    <hr />
  +
  +    <h2><a id="simple" name="simple">Simple dynamic virtual
  +    hosts</a></h2>
  +
  +    <p>This extract from <code>httpd.conf</code> implements the
  +    virtual host arrangement outlined in the <a
  +    href="#motivation">Motivation</a> section above, but in a
  +    generic fashion using <code>mod_vhost_alias</code>.</p>
  +<pre>
   # get the server name from the Host: header
   UseCanonicalName Off
   
  @@ -151,25 +181,26 @@
   # include the server name in the filenames used to satisfy requests
   VirtualDocumentRoot /www/hosts/%0/docs
   VirtualScriptAlias  /www/hosts/%0/cgi-bin
  -</PRE>
  -
  -<P>This configuration can be changed into an IP-based virtual hosting
  -solution by just turning <CODE>UseCanonicalName Off</CODE> into
  -<CODE>UseCanonicalName DNS</CODE>. The server name that is inserted
  -into the filename is then derived from the IP address of the virtual
  -host.</P>
  -
  -
  -<HR><H2><A NAME="homepages">A virtually hosted homepages system</A></H2>
  -
  -<P>This is an adjustment of the above system tailored for an ISP's
  -homepages server. Using a slightly more complicated configuration we
  -can select substrings of the server name to use in the filename so
  -that e.g. the documents for <SAMP>www.user.isp.com</SAMP> are found in
  -<CODE>/home/user/</CODE>. It uses a single <CODE>cgi-bin</CODE>
  -directory instead of one per virtual host.</P>
  +</pre>
   
  -<PRE>
  +    <p>This configuration can be changed into an IP-based virtual
  +    hosting solution by just turning <code>UseCanonicalName
  +    Off</code> into <code>UseCanonicalName DNS</code>. The server
  +    name that is inserted into the filename is then derived from
  +    the IP address of the virtual host.</p>
  +    <hr />
  +
  +    <h2><a id="homepages" name="homepages">A virtually hosted
  +    homepages system</a></h2>
  +
  +    <p>This is an adjustment of the above system tailored for an
  +    ISP's homepages server. Using a slightly more complicated
  +    configuration we can select substrings of the server name to
  +    use in the filename so that e.g. the documents for
  +    <samp>www.user.isp.com</samp> are found in
  +    <code>/home/user/</code>. It uses a single <code>cgi-bin</code>
  +    directory instead of one per virtual host.</p>
  +<pre>
   # all the preliminary stuff is the same as above, then
   
   # include part of the server name in the filenames
  @@ -177,72 +208,71 @@
   
   # single cgi-bin directory
   ScriptAlias  /cgi-bin/  /www/std-cgi/
  -</PRE>
  +</pre>
   
  -<P>There are examples of more complicated
  -<CODE>VirtualDocumentRoot</CODE> settings in
  -<A HREF="../mod/mod_vhost_alias.html">the
  -<CODE>mod_vhost_alias</CODE> documentation</A>.</P>
  -
  -
  -<HR><H2><A NAME="combinations">Using more than one virtual hosting
  -system on the same server</A></H2>
  -
  -<P>With more complicated setups you can use Apache's normal
  -<CODE>&lt;VirtualHost&gt;</CODE> directives to control the scope of
  -the various virtual hosting configurations. For example, you could
  -have one IP address for homepages customers and another for commercial
  -customers with the following setup. This can of course be combined
  -with conventional <CODE>&lt;VirtualHost&gt;</CODE> configuration
  -sections.</P>
  -
  -<PRE>
  +    <p>There are examples of more complicated
  +    <code>VirtualDocumentRoot</code> settings in <a
  +    href="../mod/mod_vhost_alias.html">the
  +    <code>mod_vhost_alias</code> documentation</a>.</p>
  +    <hr />
  +
  +    <h2><a id="combinations" name="combinations">Using more than
  +    one virtual hosting system on the same server</a></h2>
  +
  +    <p>With more complicated setups you can use Apache's normal
  +    <code>&lt;VirtualHost&gt;</code> directives to control the
  +    scope of the various virtual hosting configurations. For
  +    example, you could have one IP address for homepages customers
  +    and another for commercial customers with the following setup.
  +    This can of course be combined with conventional
  +    <code>&lt;VirtualHost&gt;</code> configuration sections.</p>
  +<pre>
   UseCanonicalName Off
   
   LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
   
   &lt;Directory /www/commercial&gt;
  -	Options FollowSymLinks
  -	AllowOverride All
  +    Options FollowSymLinks
  +    AllowOverride All
   &lt;/Directory&gt;
   
   &lt;Directory /www/homepages&gt;
  -	Options FollowSymLinks
  -	AllowOverride None
  +    Options FollowSymLinks
  +    AllowOverride None
   &lt;/Directory&gt;
   
   &lt;VirtualHost 111.22.33.44&gt;
  -	ServerName www.commercial.isp.com
  +    ServerName www.commercial.isp.com
   
  -	CustomLog logs/access_log.commercial vcommon
  +    CustomLog logs/access_log.commercial vcommon
   
  -	VirtualDocumentRoot /www/commercial/%0/docs
  -	VirtualScriptAlias  /www/commercial/%0/cgi-bin
  +    VirtualDocumentRoot /www/commercial/%0/docs
  +    VirtualScriptAlias  /www/commercial/%0/cgi-bin
   &lt;/VirtualHost&gt;
   
   &lt;VirtualHost 111.22.33.45&gt;
  -	ServerName www.homepages.isp.com
  +    ServerName www.homepages.isp.com
   
  -	CustomLog logs/access_log.homepages vcommon
  +    CustomLog logs/access_log.homepages vcommon
   
  -	VirtualDocumentRoot /www/homepages/%0/docs
  -	ScriptAlias         /cgi-bin/ /www/std-cgi/
  +    VirtualDocumentRoot /www/homepages/%0/docs
  +    ScriptAlias         /cgi-bin/ /www/std-cgi/
   &lt;/VirtualHost&gt;
  -</PRE>
  -
  -
  -<HR><H2><A NAME="ipbased">More efficient IP-based virtual hosting</A></H2>
  +</pre>
  +    <hr />
   
  -<P>After <A HREF="#simple">the first example</A> I noted that it is
  -easy to turn it into an IP-based virtual hosting setup. Unfortunately
  -that configuration is not very efficient because it requires a DNS
  -lookup for every request. This can be avoided by laying out the
  -filesystem according to the IP addresses themselves rather than the
  -corresponding names and changing the logging similarly. Apache will
  -then usually not need to work out the server name and so incur a DNS
  -lookup.</P>
  +    <h2><a id="ipbased" name="ipbased">More efficient IP-based
  +    virtual hosting</a></h2>
   
  -<PRE>
  +    <p>After <a href="#simple">the first example</a> I noted that
  +    it is easy to turn it into an IP-based virtual hosting setup.
  +    Unfortunately that configuration is not very efficient because
  +    it requires a DNS lookup for every request. This can be avoided
  +    by laying out the filesystem according to the IP addresses
  +    themselves rather than the corresponding names and changing the
  +    logging similarly. Apache will then usually not need to work
  +    out the server name and so incur a DNS lookup.</p>
  +<pre>
   # get the server name from the reverse DNS of the IP address
   UseCanonicalName DNS
   
  @@ -253,48 +283,51 @@
   # include the IP address in the filenames
   VirtualDocumentRootIP /www/hosts/%0/docs
   VirtualScriptAliasIP  /www/hosts/%0/cgi-bin
  -</PRE>
  -
  -
  -<HR><H2><A NAME="oldversion">Using older versions of Apache</A></H2>
  +</pre>
  +    <hr />
   
  -<P>The examples above rely on <CODE>mod_vhost_alias</CODE> which
  -appeared after version 1.3.6. If you are using a version of Apache
  -without <CODE>mod_vhost_alias</CODE> then you can implement this
  -technique with <CODE>mod_rewrite</CODE> as illustrated below, but
  -only for Host:-header-based virtual hosts.</P>
  -
  -<P>In addition there are some things to beware of with logging. Apache
  -1.3.6 is the first version to include the <CODE>%V</CODE> log format
  -directive; in versions 1.3.0 - 1.3.3 the <CODE>%v</CODE> option did
  -what <CODE>%V</CODE> does; version 1.3.4 has no equivalent. In
  -all these versions of Apache the <CODE>UseCanonicalName</CODE>
  -directive can appear in <CODE>.htaccess</CODE> files which means that
  -customers can cause the wrong thing to be logged. Therefore the best
  -thing to do is use the <CODE>%{Host}i</CODE> directive which logs the
  -<CODE>Host:</CODE> header directly; note that this may include
  -<CODE>:port</CODE> on the end which is not the case for
  -<CODE>%V</CODE>.</P>
  -
  -
  -<HR><H2><A NAME="simple.rewrite">Simple dynamic virtual hosts
  -using <CODE>mod_rewrite</CODE></A></H2>
  -
  -<P>This extract from <CODE>httpd.conf</CODE> does the same thing as
  -<A HREF="#simple">the first example</A>. The first half is very
  -similar to the corresponding part above but with some changes for
  -backward compatibility and to make the <CODE>mod_rewrite</CODE> part
  -work properly; the second half configures <CODE>mod_rewrite</CODE> to
  -do the actual work.</P>
  -
  -<P>There are a couple of especially tricky bits: By default,
  -<CODE>mod_rewrite</CODE> runs before the other URI translation modules
  -(<CODE>mod_alias</CODE> etc.) so if they are used then
  -<CODE>mod_rewrite</CODE> must be configured to accommodate them.
  -Also, mome magic must be performed to do a per-dynamic-virtual-host
  -equivalent of <CODE>ScriptAlias</CODE>.</P>
  +    <h2><a id="oldversion" name="oldversion">Using older versions
  +    of Apache</a></h2>
   
  -<PRE>
  +    <p>The examples above rely on <code>mod_vhost_alias</code>
  +    which appeared after version 1.3.6. If you are using a version
  +    of Apache without <code>mod_vhost_alias</code> then you can
  +    implement this technique with <code>mod_rewrite</code> as
  +    illustrated below, but only for Host:-header-based virtual
  +    hosts.</p>
  +
  +    <p>In addition there are some things to beware of with logging.
  +    Apache 1.3.6 is the first version to include the
  +    <code>%V</code> log format directive; in versions 1.3.0 - 1.3.3
  +    the <code>%v</code> option did what <code>%V</code> does;
  +    version 1.3.4 has no equivalent. In all these versions of
  +    Apache the <code>UseCanonicalName</code> directive can appear
  +    in <code>.htaccess</code> files which means that customers can
  +    cause the wrong thing to be logged. Therefore the best thing to
  +    do is use the <code>%{Host}i</code> directive which logs the
  +    <code>Host:</code> header directly; note that this may include
  +    <code>:port</code> on the end which is not the case for
  +    <code>%V</code>.</p>
  +    <hr />
  +
  +    <h2><a id="simple.rewrite" name="simple.rewrite">Simple dynamic
  +    virtual hosts using <code>mod_rewrite</code></a></h2>
  +
  +    <p>This extract from <code>httpd.conf</code> does the same
  +    thing as <a href="#simple">the first example</a>. The first
  +    half is very similar to the corresponding part above but with
  +    some changes for backward compatibility and to make the
  +    <code>mod_rewrite</code> part work properly; the second half
  +    configures <code>mod_rewrite</code> to do the actual work.</p>
  +
  +    <p>There are a couple of especially tricky bits: By default,
  +    <code>mod_rewrite</code> runs before the other URI translation
  +    modules (<code>mod_alias</code> etc.) so if they are used then
  +    <code>mod_rewrite</code> must be configured to accommodate
  +    them. Also, mome magic must be performed to do a
  +    per-dynamic-virtual-host equivalent of
  +    <code>ScriptAlias</code>.</p>
  +<pre>
   # get the server name from the Host: header
   UseCanonicalName Off
   
  @@ -303,9 +336,9 @@
   CustomLog logs/access_log vcommon
   
   &lt;Directory /www/hosts&gt;
  -	# ExecCGI is needed here because we can't force
  -	# CGI execution in the way that ScriptAlias does
  -	Options FollowSymLinks ExecCGI
  +    # ExecCGI is needed here because we can't force
  +    # CGI execution in the way that ScriptAlias does
  +    Options FollowSymLinks ExecCGI
   &lt;/Directory&gt;
   
   # now for the hard bit
  @@ -328,16 +361,15 @@
   RewriteRule  ^/(.*)$  /www/hosts/${lowercase:%{SERVER_NAME}}/cgi-bin/$1  [T=application/x-httpd-cgi]
   
   # that's it!
  -</PRE>
  +</pre>
  +    <hr />
   
  +    <h2><a id="homepages.rewrite" name="homepages.rewrite">A
  +    homepages system using <code>mod_rewrite</code></a></h2>
   
  -<HR><H2><A NAME="homepages.rewrite">A homepages system
  -using <CODE>mod_rewrite</CODE></A></H2>
  -
  -<P>This does the same thing as <A HREF="#homepages">the
  -second example</A>.</P>
  -
  -<PRE>
  +    <p>This does the same thing as <a href="#homepages">the second
  +    example</a>.</p>
  +<pre>
   RewriteEngine on
   
   RewriteMap   lowercase  int:tolower
  @@ -357,27 +389,31 @@
   
   # define the global CGI directory
   ScriptAlias  /cgi-bin/  /www/std-cgi/
  -</PRE>
  -
  -
  -<HR><H2><A NAME="xtra-conf">Using a separate virtual host configuration file</A></H2>
  +</pre>
  +    <hr />
   
  -<P>This arrangement uses more advanced <CODE>mod_rewrite</CODE>
  -features to get the translation from virtual host to document root
  -from a separate configuration file. This provides more flexibility but
  -requires more complicated configuration.</P>
  +    <h2><a id="xtra-conf" name="xtra-conf">Using a separate virtual
  +    host configuration file</a></h2>
   
  -<P>The <CODE>vhost.map</CODE> file contains something like this:
  -<PRE>
  +    <p>This arrangement uses more advanced <code>mod_rewrite</code>
  +    features to get the translation from virtual host to document
  +    root from a separate configuration file. This provides more
  +    flexibility but requires more complicated configuration.</p>
  +
  +    <p>The <code>vhost.map</code> file contains something like
  +    this:</p>
  +<pre>
   www.customer-1.com  /www/customers/1
   www.customer-2.com  /www/customers/2
   # ...
   www.customer-N.com  /www/customers/N
  -</PRE>
  -</P>
  +</pre>
  +    <br />
  +     <br />
  +     
   
  -<P>The <CODE>http.conf</CODE> contains this:
  -<PRE>
  +    <p>The <code>http.conf</code> contains this:</p>
  +<pre>
   RewriteEngine on
   
   RewriteMap   lowercase  int:tolower
  @@ -397,9 +433,10 @@
   RewriteCond  ${lowercase:%{SERVER_NAME}}  ^(.+)$
   RewriteCond  ${vhost:%1}                  ^(/.*)$
   RewriteRule  ^/(.*)$                      %1/cgi-bin/$1
  -</PRE>
  -</P>
  +</pre>
  +    <br />
  +     <br />
  +     <!--#include virtual="footer.html" -->
  +  </body>
  +</html>
   
  -<!--#include virtual="footer.html" -->
  -</BODY>
  -</HTML>
  
  
  
  1.14      +148 -144  httpd-2.0/docs/manual/vhosts/name-based.html
  
  Index: name-based.html
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/docs/manual/vhosts/name-based.html,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- name-based.html	2000/10/19 23:33:40	1.13
  +++ name-based.html	2001/09/22 19:39:26	1.14
  @@ -1,64 +1,65 @@
  -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
  -<HTML><HEAD>
  -<TITLE>Apache name-based Virtual Hosts</TITLE>
  -</HEAD>
  -
  -<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  -<BODY
  - BGCOLOR="#FFFFFF"
  - TEXT="#000000"
  - LINK="#0000FF"
  - VLINK="#000080"
  - ALINK="#FF0000"
  ->
  -<!--#include virtual="header.html" -->
  -<H1 ALIGN="CENTER">Apache name-based Virtual Host Support</H1>
  -
  -<STRONG>See Also:</STRONG>
  -<A HREF="ip-based.html">IP-based Virtual Host Support</A>
  -
  -<HR>
  -
  -<H2>Name-based vs. IP-based virtual hosts</H2>
  -
  -<P>Early versions of HTTP (like many other protocols, e.g. FTP)
  -required a different IP address for each virtual host on the server.
  -On some platforms this can limit the number of virtual hosts you can
  -run, and because there are concerns about the availability of IP
  -addresses it is strongly discouraged by the registraries (ARIN, RIPE,
  -and APNIC).</P>
  -
  -<P>The <CODE>HTTP/1.1</CODE> protocol, and a common extension to
  -<CODE>HTTP/1.0</CODE>, includes a method for the server to identify
  -what name it is being addressed as. Apache 1.1 and later support this
  -approach as well as the old IP-address-per-hostname method.</P>
  -
  -<P>The benefits of using the name-based virtual hosts is a practically
  -unlimited number of servers, ease of configuration and use, and it
  -requires no additional hardware or software. The main disadvantage is
  -that the client must support this part of the protocol. Almost all
  -browsers do, but there are still tiny numbers of very old browsers in
  -use which do not. This can cause problems, although a possible
  -solution is addressed below.</P>
  -
  -<H2>Using name-based virtual hosts</H2>
  -
  -<P>Using name-based virtual hosts is quite easy, and superficially looks
  -like the old method. The notable difference between IP-based and
  -name-based virtual host configuration is the
  -<A HREF="../mod/core.html#namevirtualhost"><CODE>NameVirtualHost</CODE></A>
  -directive which specifies an IP address that should be used as a
  -target for name-based virtual hosts, or the wildcard <CODE>*</CODE> to
  -indicate that the server only does name-based virtual hosting (no
  -IP-based virtual hosting).</P>
  -
  -<P>For example, suppose that both <SAMP>www.domain.tld</SAMP> and
  -<SAMP>www.otherdomain.tld</SAMP> point at the IP address of your
  -server. Then you simply add to one of the Apache configuration files
  -(most likely <CODE>httpd.conf</CODE> or <CODE>srm.conf</CODE>) code
  -similar to the following:</P>
  +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  +    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   
  -<PRE>
  +<html xmlns="http://www.w3.org/1999/xhtml">
  +  <head>
  +    <meta name="generator" content="HTML Tidy, see www.w3.org" />
  +
  +    <title>Apache name-based Virtual Hosts</title>
  +  </head>
  +  <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  +
  +  <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
  +  vlink="#000080" alink="#FF0000">
  +    <!--#include virtual="header.html" -->
  +
  +    <h1 align="CENTER">Apache name-based Virtual Host Support</h1>
  +    <strong>See Also:</strong> <a href="ip-based.html">IP-based
  +    Virtual Host Support</a> 
  +    <hr />
  +
  +    <h2>Name-based vs. IP-based virtual hosts</h2>
  +
  +    <p>Early versions of HTTP (like many other protocols, e.g. FTP)
  +    required a different IP address for each virtual host on the
  +    server. On some platforms this can limit the number of virtual
  +    hosts you can run, and because there are concerns about the
  +    availability of IP addresses it is strongly discouraged by the
  +    registraries (ARIN, RIPE, and APNIC).</p>
  +
  +    <p>The <code>HTTP/1.1</code> protocol, and a common extension
  +    to <code>HTTP/1.0</code>, includes a method for the server to
  +    identify what name it is being addressed as. Apache 1.1 and
  +    later support this approach as well as the old
  +    IP-address-per-hostname method.</p>
  +
  +    <p>The benefits of using the name-based virtual hosts is a
  +    practically unlimited number of servers, ease of configuration
  +    and use, and it requires no additional hardware or software.
  +    The main disadvantage is that the client must support this part
  +    of the protocol. Almost all browsers do, but there are still
  +    tiny numbers of very old browsers in use which do not. This can
  +    cause problems, although a possible solution is addressed
  +    below.</p>
  +
  +    <h2>Using name-based virtual hosts</h2>
  +
  +    <p>Using name-based virtual hosts is quite easy, and
  +    superficially looks like the old method. The notable difference
  +    between IP-based and name-based virtual host configuration is
  +    the <a
  +    href="../mod/core.html#namevirtualhost"><code>NameVirtualHost</code></a>
  +    directive which specifies an IP address that should be used as
  +    a target for name-based virtual hosts, or the wildcard
  +    <code>*</code> to indicate that the server only does name-based
  +    virtual hosting (no IP-based virtual hosting).</p>
  +
  +    <p>For example, suppose that both <samp>www.domain.tld</samp>
  +    and <samp>www.otherdomain.tld</samp> point at the IP address of
  +    your server. Then you simply add to one of the Apache
  +    configuration files (most likely <code>httpd.conf</code> or
  +    <code>srm.conf</code>) code similar to the following:</p>
  +<pre>
       NameVirtualHost *
   
       &lt;VirtualHost *&gt;
  @@ -70,68 +71,69 @@
       ServerName www.otherdomain.tld
       DocumentRoot /www/otherdomain
       &lt;/VirtualHost&gt;
  -</PRE>
  +</pre>
   
  -<P>Of course, any additional directives can (and should) be placed
  -into the <CODE>&lt;VirtualHost&gt;</CODE> section. To make this work,
  -all that is needed is to make sure that the names
  -<SAMP>www.domain.tld</SAMP> and <SAMP>www.otherdomain.tld</SAMP>
  -are pointing to the right IP address.
  -
  -<P>Note: When you specify an IP address in a <CODE>NameVirtualHost</CODE>
  -directive then requests to that IP address will only ever be served
  -by matching &lt;VirtualHost&gt;s.  The "main server" will
  -<STRONG>never</STRONG> be served from the specified IP address.
  -If you specify a wildcard then the "main server" isn't used at all.
  -If you start to use virtual hosts you should stop using the "main server"
  -as an independent server and rather use it as a place for
  -configuration directives that are common for all your virtual hosts.
  -In other words, you should add a &lt;VirtualHost&gt; section for
  -<EM>every</EM> server (hostname) you want to maintain on your server.
  -
  -<P>Additionally, many servers may wish to be accessible by more than
  -one name. For example, the example server might want to be accessible
  -as <CODE>domain.tld</CODE>, or <CODE>www2.domain.tld</CODE>, assuming
  -the IP addresses pointed to the same server. In fact, one might want it
  -so that all addresses at <CODE>domain.tld</CODE> were picked up by the
  -server. This is possible with the
  -<A HREF="../mod/core.html#serveralias"><CODE>ServerAlias</CODE></A>
  -directive, placed inside the &lt;VirtualHost&gt; section. For
  -example:</P>
  -
  -<PRE>
  +    <p>Of course, any additional directives can (and should) be
  +    placed into the <code>&lt;VirtualHost&gt;</code> section. To
  +    make this work, all that is needed is to make sure that the
  +    names <samp>www.domain.tld</samp> and
  +    <samp>www.otherdomain.tld</samp> are pointing to the right IP
  +    address.</p>
  +
  +    <p>Note: When you specify an IP address in a
  +    <code>NameVirtualHost</code> directive then requests to that IP
  +    address will only ever be served by matching
  +    &lt;VirtualHost&gt;s. The "main server" will
  +    <strong>never</strong> be served from the specified IP address.
  +    If you specify a wildcard then the "main server" isn't used at
  +    all. If you start to use virtual hosts you should stop using
  +    the "main server" as an independent server and rather use it as
  +    a place for configuration directives that are common for all
  +    your virtual hosts. In other words, you should add a
  +    &lt;VirtualHost&gt; section for <em>every</em> server
  +    (hostname) you want to maintain on your server.</p>
  +
  +    <p>Additionally, many servers may wish to be accessible by more
  +    than one name. For example, the example server might want to be
  +    accessible as <code>domain.tld</code>, or
  +    <code>www2.domain.tld</code>, assuming the IP addresses pointed
  +    to the same server. In fact, one might want it so that all
  +    addresses at <code>domain.tld</code> were picked up by the
  +    server. This is possible with the <a
  +    href="../mod/core.html#serveralias"><code>ServerAlias</code></a>
  +    directive, placed inside the &lt;VirtualHost&gt; section. For
  +    example:</p>
  +<pre>
       ServerAlias domain.tld *.domain.tld
  -</PRE>
  -
  -<P>Note that you can use <CODE>*</CODE> and <CODE>?</CODE> as wild-card
  -characters.</P>
  +</pre>
   
  -<P>You also might need <CODE>ServerAlias</CODE> if you are
  -serving local users who do not always include the domain name.
  -For example, if local users are
  -familiar with typing "www" or "www.foobar" then you will need to add
  -<CODE>ServerAlias www www.foobar</CODE>.  It isn't possible for the
  -server to know what domain the client uses for their name resolution
  -because the client doesn't provide that information in the request.
  -The <CODE>ServerAlias</CODE> directive is generally a way to have different
  -hostnames pointing to the same virtual host.
  -</P>
  -
  -<H2>Compatibility with Older Browsers</H2>
  -
  -<P>As mentioned earlier, there are still some clients in use who
  -do not send the required data for the name-based virtual hosts to work
  -properly. These clients will always be sent the pages from the
  -first virtual host listed for that IP address (the
  -<CITE>primary</CITE> name-based virtual host).</P>
  -
  -<P>There is a possible workaround with the
  -<A HREF="../mod/core.html#serverpath"><CODE>ServerPath</CODE></A>
  -directive, albeit a slightly cumbersome one:</P>
  +    <p>Note that you can use <code>*</code> and <code>?</code> as
  +    wild-card characters.</p>
   
  -<P>Example configuration:
  +    <p>You also might need <code>ServerAlias</code> if you are
  +    serving local users who do not always include the domain name.
  +    For example, if local users are familiar with typing "www" or
  +    "www.foobar" then you will need to add <code>ServerAlias www
  +    www.foobar</code>. It isn't possible for the server to know
  +    what domain the client uses for their name resolution because
  +    the client doesn't provide that information in the request. The
  +    <code>ServerAlias</code> directive is generally a way to have
  +    different hostnames pointing to the same virtual host.</p>
  +
  +    <h2>Compatibility with Older Browsers</h2>
  +
  +    <p>As mentioned earlier, there are still some clients in use
  +    who do not send the required data for the name-based virtual
  +    hosts to work properly. These clients will always be sent the
  +    pages from the first virtual host listed for that IP address
  +    (the <cite>primary</cite> name-based virtual host).</p>
  +
  +    <p>There is a possible workaround with the <a
  +    href="../mod/core.html#serverpath"><code>ServerPath</code></a>
  +    directive, albeit a slightly cumbersome one:</p>
   
  -<PRE>
  +    <p>Example configuration:</p>
  +<pre>
       NameVirtualHost 111.22.33.44
   
       &lt;VirtualHost 111.22.33.44&gt;
  @@ -139,31 +141,33 @@
       ServerPath /domain
       DocumentRoot /web/domain
       &lt;/VirtualHost&gt;
  -</PRE>
  +</pre>
  +
  +    <p>What does this mean? It means that a request for any URI
  +    beginning with "<samp>/domain</samp>" will be served from the
  +    virtual host <samp>www.domain.tld</samp> This means that the
  +    pages can be accessed as
  +    <code>http://www.domain.tld/domain/</code> for all clients,
  +    although clients sending a <samp>Host:</samp> header can also
  +    access it as <code>http://www.domain.tld/</code>.</p>
  +
  +    <p>In order to make this work, put a link on your primary
  +    virtual host's page to
  +    <samp>http://www.domain.tld/domain/</samp> Then, in the virtual
  +    host's pages, be sure to use either purely relative links
  +    (<em>e.g.</em>, "<samp>file.html</samp>" or
  +    "<samp>../icons/image.gif</samp>" or links containing the
  +    prefacing <samp>/domain/</samp> (<em>e.g.</em>,
  +    "<samp>http://www.domain.tld/domain/misc/file.html</samp>" or
  +    "<samp>/domain/misc/file.html</samp>").</p>
  +
  +    <p>This requires a bit of discipline, but adherence to these
  +    guidelines will, for the most part, ensure that your pages will
  +    work with all browsers, new and old.</p>
  +
  +    <p>See also: <a href="examples.html#serverpath">ServerPath
  +    configuration example</a></p>
  +    <!--#include virtual="footer.html" -->
  +  </body>
  +</html>
   
  -<P>What does this mean? It means that a request for any URI beginning
  -with "<SAMP>/domain</SAMP>" will be served from the virtual host
  -<SAMP>www.domain.tld</SAMP> This means that the pages can be accessed as
  -<CODE>http://www.domain.tld/domain/</CODE> for all clients, although
  -clients sending a <SAMP>Host:</SAMP> header can also access it as
  -<CODE>http://www.domain.tld/</CODE>.</P>
  -
  -<P>In order to make this work, put a link on your primary virtual host's page
  -to <SAMP>http://www.domain.tld/domain/</SAMP>
  -Then, in the virtual host's pages, be sure to use either purely
  -relative links (<EM>e.g.</EM>, "<SAMP>file.html</SAMP>" or
  -"<SAMP>../icons/image.gif</SAMP>" or links containing the prefacing
  -<SAMP>/domain/</SAMP>
  -(<EM>e.g.</EM>, "<SAMP>http://www.domain.tld/domain/misc/file.html</SAMP>" or
  -"<SAMP>/domain/misc/file.html</SAMP>").</P>
  -
  -<P>This requires a bit of
  -discipline, but adherence to these guidelines will, for the most part,
  -ensure that your pages will work with all browsers, new and old.</P>
  -
  -<P>See also: <A HREF="examples.html#serverpath">ServerPath configuration
  -example</A></P>
  -
  -<!--#include virtual="footer.html" -->
  -</BODY>
  -</HTML>
  
  
  

Mime
View raw message