You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by rb...@apache.org on 2001/10/08 03:37:37 UTC
cvs commit: httpd-docs-1.3/htdocs/manual/vhosts details.html details_1_2.html examples.html fd-limits.html footer.html header.html host.html index.html.en index.html.html ip-based.html mass.html name-based.html.en name-based.html.html vhosts-in-depth.html virtual-host.html
rbowen 01/10/07 18:37:37
Modified: htdocs/manual/vhosts details.html details_1_2.html
examples.html fd-limits.html footer.html
header.html host.html index.html.en index.html.html
ip-based.html mass.html name-based.html.en
name-based.html.html vhosts-in-depth.html
virtual-host.html
Log:
w3c tidy to convert to xhtml. .ja.jis files have not been done.
Revision Changes Path
1.12 +385 -369 httpd-docs-1.3/htdocs/manual/vhosts/details.html
Index: details.html
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/vhosts/details.html,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- details.html 2000/09/12 16:32:35 1.11
+++ details.html 2001/10/08 01:37:37 1.12
@@ -1,381 +1,397 @@
-<!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><VirtualHost></CODE> sections.
-There are virtual servers, called <EM>vhosts</EM>, which are defined by
-<A HREF="../mod/core.html#virtualhost"><SAMP><VirtualHost></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. In 1.3.13 and later that
-includes the IP address <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><VirtualHost></code> sections. There are virtual
+ servers, called <em>vhosts</em>, which are defined by <a
+ href="../mod/core.html#virtualhost"><samp><VirtualHost></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. In 1.3.13
+ and later that includes the IP address <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 | <VirtualHost 111.22.33.44>
<VirtualHost 111.22.33.44> | # server A
- # server A | </VirtualHost>
- ... | <VirtualHost 111.22.33.55>
- </VirtualHost> | # server C
+ # server A | </VirtualHost>
+ ... | <VirtualHost 111.22.33.55>
+ </VirtualHost> | # server C
<VirtualHost 111.22.33.44> | ...
- # server B | </VirtualHost>
- ... | <VirtualHost 111.22.33.44>
- </VirtualHost> | # server B
+ # server B | </VirtualHost>
+ ... | <VirtualHost 111.22.33.44>
+ </VirtualHost> | # server B
| ...
NameVirtualHost 111.22.33.55 | </VirtualHost>
<VirtualHost 111.22.33.55> | <VirtualHost 111.22.33.55>
- # server C | # server D
- ... | ...
- </VirtualHost> | </VirtualHost>
+ # server C | # server D
+ ... | ...
+ </VirtualHost> | </VirtualHost>
<VirtualHost 111.22.33.55> |
- # server D | NameVirtualHost 111.22.33.44
- ... | NameVirtualHost 111.22.33.55
- </VirtualHost> |
+ # server D | NameVirtualHost 111.22.33.44
+ ... | NameVirtualHost 111.22.33.55
+ </VirtualHost> |
|
-</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 "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>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 "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> 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>In Apache 1.3.13 and later, 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.
- In Apache 1.3.13 and later 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>, "ServerPath /abc" should appear after
- "ServerPath /abc/def").
- <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>In Apache 1.3.13 and later, 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. In Apache 1.3.13 and later
+ 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.6 +373 -383 httpd-docs-1.3/htdocs/manual/vhosts/details_1_2.html
Index: details_1_2.html
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/vhosts/details_1_2.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- details_1_2.html 1998/08/19 06:16:56 1.5
+++ details_1_2.html 2001/10/08 01:37:37 1.6
@@ -1,97 +1,96 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>An In-Depth Discussion of VirtualHost 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 VirtualHost Matching</H1>
-
-<P>This is a very rough document that was probably out of date the moment
-it was written. It attempts to explain exactly what the code does when
-deciding what virtual host to serve a hit from. It's provided on the
-assumption that something is better than nothing. The server version
-under discussion is Apache 1.2.
-
-<P>If you just want to "make it work" without understanding
-how, there's a <A HREF="#whatworks">What Works</A> section at the bottom.
-
-<H3>Config File Parsing</H3>
-
-<P>There is a main_server which consists of all the definitions appearing
-outside of <CODE>VirtualHost</CODE> sections. There are virtual servers,
-called <EM>vhosts</EM>, which are defined by
-<A
- HREF="../mod/core.html#virtualhost"
-><SAMP>VirtualHost</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>ServerName</CODE>,
-<CODE>ServerPath</CODE>, or <CODE>ServerAlias</CODE>.
-
-<P>In the absence of any
-<A
- HREF="../mod/core.html#listen"
-><SAMP>Listen</SAMP></A>
-directives, the (final if there
-are multiple) <CODE>Port</CODE> directive in the main_server indicates
-which port httpd will listen on.
-
-<P> The <CODE>Port</CODE> and <CODE>ServerName</CODE> directives for
-any server main or virtual are used when generating URLs such as during
-redirects.
-
-<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> The magic <CODE>_default_</CODE> address has significance during
-the matching algorithm. It essentially matches any unspecified address.
-
-<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. 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). Note that subsequent <CODE>Port</CODE>
-statements for this vhost will not affect the ports assigned in the
-address set.
-
-<P>
-All vhosts are stored in a list which is in the reverse order that
-they appeared in the config file. For example, if the config file is:
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<BLOCKQUOTE><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 VirtualHost 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 VirtualHost
+ Matching</h1>
+
+ <p>This is a very rough document that was probably out of date
+ the moment it was written. It attempts to explain exactly what
+ the code does when deciding what virtual host to serve a hit
+ from. It's provided on the assumption that something is better
+ than nothing. The server version under discussion is Apache
+ 1.2.</p>
+
+ <p>If you just want to "make it work" without understanding
+ how, there's a <a href="#whatworks">What Works</a> section at
+ the bottom.</p>
+
+ <h3>Config File Parsing</h3>
+
+ <p>There is a main_server which consists of all the definitions
+ appearing outside of <code>VirtualHost</code> sections. There
+ are virtual servers, called <em>vhosts</em>, which are defined
+ by <a
+ href="../mod/core.html#virtualhost"><samp>VirtualHost</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>ServerName</code>, <code>ServerPath</code>, or
+ <code>ServerAlias</code>.</p>
+
+ <p>In the absence of any <a
+ href="../mod/core.html#listen"><samp>Listen</samp></a>
+ directives, the (final if there are multiple) <code>Port</code>
+ directive in the main_server indicates which port httpd will
+ listen on.</p>
+
+ <p>The <code>Port</code> and <code>ServerName</code> directives
+ for any server main or virtual are used when generating URLs
+ such as during redirects.</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>The magic <code>_default_</code> address has significance
+ during the matching algorithm. It essentially matches any
+ unspecified address.</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. 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). Note that subsequent
+ <code>Port</code> statements for this vhost will not affect the
+ ports assigned in the address set.</p>
+
+ <p>All vhosts are stored in a list which is in the reverse
+ order that they appeared in the config file. For example, if
+ the config file is:</p>
+
+ <blockquote>
+<pre>
<VirtualHost A>
...
</VirtualHost>
@@ -103,294 +102,285 @@
<VirtualHost C>
...
</VirtualHost>
-</PRE></BLOCKQUOTE>
-
-Then the list will be ordered: main_server, C, B, A. Keep this in mind.
+</pre>
+ </blockquote>
+ Then the list will be ordered: main_server, C, B, A. Keep this
+ in mind.
+
+ <p>After parsing has completed, the list of servers is scanned,
+ and various merges and 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>Now a pass is made through the vhosts to fill in any missing
+ <code>ServerName</code> fields and to classify the vhost as
+ either an <em>IP-based</em> vhost or a <em>name-based</em>
+ vhost. A vhost is considered a name-based vhost if any of its
+ address set overlaps the main_server (the port associated with
+ each address must match the main_server's <code>Port</code>).
+ Otherwise it is considered an IP-based vhost.</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. Any
+ vhost that includes the magic <samp>_default_</samp> wildcard
+ is given the same <code>ServerName</code> as the main_server.
+ Otherwise the vhost (which is necessarily an IP-based vhost) is
+ given a <code>ServerName</code> based on the result of a
+ reverse DNS lookup on the first address given in the
+ <code>VirtualHost</code> statement.</p>
+
+ <h3>Vhost Matching</h3>
+
+ <p><strong>Apache 1.3 differs from what is documented here, and
+ documentation still has to be written.</strong></p>
+
+ <p>The server determines which vhost to use for a request as
+ follows:</p>
+
+ <p><code>find_virtual_server</code>: When the connection is
+ first made by the client, the local IP address (the IP address
+ to which the client connected) is looked up in the server list.
+ A vhost is matched if it is an IP-based vhost, the IP address
+ matches and the port matches (taking into account
+ wildcards).</p>
+
+ <p>If no vhosts are matched then the last occurrence, if it
+ appears, of a <samp>_default_</samp> address (which if you
+ recall the ordering of the server list mentioned above means
+ that this would be the first occurrence of
+ <samp>_default_</samp> in the config file) is matched.</p>
+
+ <p>In any event, if nothing above has matched, then the
+ main_server is matched.</p>
+
+ <p>The vhost resulting from the above search is stored with
+ data about the connection. We'll call this the <em>connection
+ vhost</em>. The connection vhost is constant over all requests
+ in a particular TCP/IP session -- that is, over all requests in
+ a KeepAlive/persistent session.</p>
+
+ <p>For each request made on the connection the following
+ sequence of events further determines the actual vhost that
+ will be used to serve the request.</p>
+
+ <p><code>check_fulluri</code>: If the requestURI is an
+ absoluteURI, that is it includes <code>http://hostname/</code>,
+ then an attempt is made to determine if the hostname's address
+ (and optional port) match that of the connection vhost. If it
+ does then the hostname portion of the URI is saved as the
+ <em>request_hostname</em>. If it does not match, then the URI
+ remains untouched. <strong>Note</strong>: to achieve this
+ address comparison, the hostname supplied goes through a DNS
+ lookup unless it matches the <code>ServerName</code> or the
+ local IP address of the client's socket.</p>
+
+ <p><code>parse_uri</code>: If the URI begins with a protocol
+ (<em>i.e.</em>, <code>http:</code>, <code>ftp:</code>) then the
+ request is considered a proxy request. Note that even though we
+ may have stripped an <code>http://hostname/</code> in the
+ previous step, this could still be a proxy request.</p>
+
+ <p><code>read_request</code>: If the request does not have a
+ hostname from the earlier step, then any <code>Host:</code>
+ header sent by the client is used as the request hostname.</p>
+
+ <p><code>check_hostalias</code>: If the request now has a
+ hostname, then an attempt is made to match for this hostname.
+ The first step of this match is to compare any port, if one was
+ given in the request, against the <code>Port</code> field of
+ the connection vhost. If there's a mismatch then the vhost used
+ for the request is the connection vhost. (This is a bug, see
+ observations.)</p>
+
+ <p>If the port matches, then httpd scans the list of vhosts
+ starting with the next server <strong>after</strong> the
+ connection vhost. This scan does not stop if there are any
+ matches, it goes through all possible vhosts, and in the end
+ uses the last match it found. The comparisons performed are as
+ follows:</p>
+
+ <ul>
+ <li>Compare the request hostname:port with the vhost
+ <code>ServerName</code> and <code>Port</code>.</li>
+
+ <li>Compare the request hostname against any and all
+ addresses given in the <code>VirtualHost</code> directive for
+ this vhost.</li>
+
+ <li>Compare the request hostname against the
+ <code>ServerAlias</code> given for the vhost.</li>
+ </ul>
+
+ <p><code>check_serverpath</code>: If the request has no
+ hostname (back up a few paragraphs) then a scan similar to the
+ one in <code>check_hostalias</code> is performed to match any
+ <code>ServerPath</code> directives given in the vhosts. Note
+ that the <strong>last match</strong> is used regardless (again
+ consider the ordering of the virtual hosts).</p>
+
+ <h3>Observations</h3>
+
+ <ul>
+ <li>It is difficult to define an IP-based vhost for the
+ machine's "main IP address". You essentially have to create a
+ bogus <code>ServerName</code> for the main_server that does
+ not match the machine's IPs.</li>
+
+ <li>
+ During the scans in both <code>check_hostalias</code> and
+ <code>check_serverpath</code> no check is made that the
+ vhost being scanned is actually a name-based vhost. This
+ means, for example, that it's possible to match an IP-based
+ vhost through another address. But because the scan starts
+ in the vhost list at the first vhost that matched the local
+ IP address of the connection, not all IP-based vhosts can
+ be matched.
+
+ <p>Consider the config file above with three vhosts A, B,
+ C. Suppose that B is a named-based vhost, and A and C are
+ IP-based vhosts. If a request comes in on B or C's address
+ containing a header "<samp>Host: A</samp>" then it will be
+ served from A's config. If a request comes in on A's
+ address then it will always be served from A's config
+ regardless of any Host: header.</p>
+ </li>
+
+ <li>
+ Unless you have a <samp>_default_</samp> vhost, it doesn't
+ matter if you mix name-based vhosts in amongst IP-based
+ vhosts. During the <code>find_virtual_server</code> phase
+ above no named-based vhost will be matched, so the
+ main_server will remain the connection vhost. Then scans
+ will cover all vhosts in the vhost list.
+
+ <p>If you do have a <samp>_default_</samp> vhost, then you
+ cannot place named-based vhosts after it in the config.
+ This is because on any connection to the main server IPs
+ the connection vhost will always be the
+ <samp>_default_</samp> vhost since none of the name-based
+ are considered during <code>find_virtual_server</code>.</p>
+ </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. <a href="dns-caveats.html">There's more
+ information available on this and the next two
+ topics</a>.</li>
+
+ <li><code>ServerName</code> should always be set for each
+ vhost. Otherwise A DNS lookup is required for each
+ vhost.</li>
+
+ <li>A DNS lookup is always required for the main_server's
+ <code>ServerName</code> (or to generate that if it isn't
+ specified in the config).</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 Host header was available to disambiguate
+ the two.)</li>
+
+ <li>If a vhost that would otherwise be a name-vhost includes
+ a <code>Port</code> statement that doesn't match the
+ main_server <code>Port</code> then it will be considered an
+ IP-based vhost. Then <code>find_virtual_server</code> will
+ match it (because the ports associated with each address in
+ the address set default to the port of the main_server) as
+ the connection vhost. Then <code>check_hostalias</code> will
+ refuse to check any other name-based vhost because of the
+ port mismatch. The result is that the vhost will steal all
+ hits going to the main_server address.</li>
+
+ <li>If two IP-based vhosts have an address in common, the
+ vhost appearing later in the file is always matched. Such a
+ thing might happen inadvertently. If the config has
+ name-based vhosts and for some reason the main_server
+ <code>ServerName</code> resolves to the wrong address then
+ all the name-based vhosts will be parsed as ip-based vhosts.
+ Then the last of them will steal all the hits.</li>
+
+ <li>The last name-based vhost in the config is always matched
+ for any hit which doesn't match one of the other name-based
+ vhosts.</li>
+ </ul>
+
+ <h3><a id="whatworks" name="whatworks">What Works</a></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 VirtualHost
+ definitions. (This is to aid the readability of the
+ configuration -- the post-config merging process makes it
+ non-obvious that definitions mixed in around virtualhosts
+ might affect all virtualhosts.)</li>
+
+ <li>Arrange your VirtualHosts such that all name-based
+ virtual hosts come first, followed by IP-based virtual hosts,
+ followed by any <samp>_default_</samp> virtual host</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 /abcdef").</li>
+
+ <li>Do not use <em>port-based</em> vhosts in the same server
+ as name-based vhosts. A loose definition for port-based is a
+ vhost which is determined by the port on the server
+ (<em>i.e.</em>, one server with ports 8000, 8080, and 80 -
+ all of which have different configurations).</li>
+ </ul>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
-<P>
-After parsing has completed, the list of servers is scanned, and various
-merges and 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 "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>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 "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> Now a pass is made through the vhosts to fill in any missing
-<CODE>ServerName</CODE> fields and to classify the vhost as either
-an <EM>IP-based</EM> vhost or a <EM>name-based</EM> vhost. A vhost is
-considered a name-based vhost if any of its address set overlaps the
-main_server (the port associated with each address must match the
-main_server's <CODE>Port</CODE>). Otherwise it is considered an IP-based
-vhost.
-
-<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. Any vhost that includes the magic
-<SAMP>_default_</SAMP> wildcard is given the same <CODE>ServerName</CODE> as
-the main_server. Otherwise the vhost (which is necessarily an IP-based
-vhost) is given a <CODE>ServerName</CODE> based on the result of a reverse
-DNS lookup on the first address given in the <CODE>VirtualHost</CODE>
-statement.
-
-<P>
-
-<H3>Vhost Matching</H3>
-
-
-<P><STRONG>Apache 1.3 differs from what is documented
-here, and documentation still has to be written.</STRONG>
-
-<P>
-The server determines which vhost to use for a request as follows:
-
-<P> <CODE>find_virtual_server</CODE>: When the connection is first made
-by the client, the local IP address (the IP address to which the client
-connected) is looked up in the server list. A vhost is matched if it
-is an IP-based vhost, the IP address matches and the port matches
-(taking into account wildcards).
-
-<P> If no vhosts are matched then the last occurrence, if it appears,
-of a <SAMP>_default_</SAMP> address (which if you recall the ordering of the
-server list mentioned above means that this would be the first occurrence
-of <SAMP>_default_</SAMP> in the config file) is matched.
-
-<P> In any event, if nothing above has matched, then the main_server is
-matched.
-
-<P> The vhost resulting from the above search is stored with data
-about the connection. We'll call this the <EM>connection vhost</EM>.
-The connection vhost is constant over all requests in a particular TCP/IP
-session -- that is, over all requests in a KeepAlive/persistent session.
-
-<P> For each request made on the connection the following sequence of
-events further determines the actual vhost that will be used to serve
-the request.
-
-<P> <CODE>check_fulluri</CODE>: If the requestURI is an absoluteURI, that
-is it includes <CODE>http://hostname/</CODE>, then an attempt is made to
-determine if the hostname's address (and optional port) match that of
-the connection vhost. If it does then the hostname portion of the URI
-is saved as the <EM>request_hostname</EM>. If it does not match, then the
-URI remains untouched. <STRONG>Note</STRONG>: to achieve this address
-comparison,
-the hostname supplied goes through a DNS lookup unless it matches the
-<CODE>ServerName</CODE> or the local IP address of the client's socket.
-
-<P> <CODE>parse_uri</CODE>: If the URI begins with a protocol
-(<EM>i.e.</EM>, <CODE>http:</CODE>, <CODE>ftp:</CODE>) then the request is
-considered a proxy request. Note that even though we may have stripped
-an <CODE>http://hostname/</CODE> in the previous step, this could still
-be a proxy request.
-
-<P> <CODE>read_request</CODE>: If the request does not have a hostname
-from the earlier step, then any <CODE>Host:</CODE> header sent by the
-client is used as the request hostname.
-
-<P> <CODE>check_hostalias</CODE>: If the request now has a hostname,
-then an attempt is made to match for this hostname. The first step
-of this match is to compare any port, if one was given in the request,
-against the <CODE>Port</CODE> field of the connection vhost. If there's
-a mismatch then the vhost used for the request is the connection vhost.
-(This is a bug, see observations.)
-
-<P>
-If the port matches, then httpd scans the list of vhosts starting with
-the next server <STRONG>after</STRONG> the connection vhost. This scan does not
-stop if there are any matches, it goes through all possible vhosts,
-and in the end uses the last match it found. The comparisons performed
-are as follows:
-
-<UL>
-<LI>Compare the request hostname:port with the vhost
- <CODE>ServerName</CODE> and <CODE>Port</CODE>.
-
-<LI>Compare the request hostname against any and all addresses given in
- the <CODE>VirtualHost</CODE> directive for this vhost.
-
-<LI>Compare the request hostname against the <CODE>ServerAlias</CODE>
- given for the vhost.
-</UL>
-
-<P>
-<CODE>check_serverpath</CODE>: If the request has no hostname
-(back up a few paragraphs) then a scan similar to the one
-in <CODE>check_hostalias</CODE> is performed to match any
-<CODE>ServerPath</CODE> directives given in the vhosts. Note that the
-<STRONG>last match</STRONG> is used regardless (again consider the ordering of
-the virtual hosts).
-
-<H3>Observations</H3>
-
-<UL>
-
-<LI>It is difficult to define an IP-based vhost for the machine's
- "main IP address". You essentially have to create a bogus
- <CODE>ServerName</CODE> for the main_server that does not match the
- machine's IPs.
- <P>
-
-<LI>During the scans in both <CODE>check_hostalias</CODE> and
- <CODE>check_serverpath</CODE> no check is made that the vhost being
- scanned is actually a name-based vhost. This means, for example, that
- it's possible to match an IP-based vhost through another address. But
- because the scan starts in the vhost list at the first vhost that
- matched the local IP address of the connection, not all IP-based vhosts
- can be matched.
- <P>
- Consider the config file above with three vhosts A, B, C. Suppose
- that B is a named-based vhost, and A and C are IP-based vhosts. If
- a request comes in on B or C's address containing a header
- "<SAMP>Host: A</SAMP>" then
- it will be served from A's config. If a request comes in on A's
- address then it will always be served from A's config regardless of
- any Host: header.
- </P>
-
-<LI>Unless you have a <SAMP>_default_</SAMP> vhost,
- it doesn't matter if you mix name-based vhosts in amongst IP-based
- vhosts. During the <CODE>find_virtual_server</CODE> phase above no
- named-based vhost will be matched, so the main_server will remain the
- connection vhost. Then scans will cover all vhosts in the vhost list.
- <P>
- If you do have a <SAMP>_default_</SAMP> vhost, then you cannot place
- named-based vhosts after it in the config. This is because on any
- connection to the main server IPs the connection vhost will always be
- the <SAMP>_default_</SAMP> vhost since none of the name-based are
- considered during <CODE>find_virtual_server</CODE>.
- </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.
- <A HREF="dns-caveats.html">There's more information
- available on this and the next two topics</A>.
- <P>
-
-<LI><CODE>ServerName</CODE> should always be set for each vhost. Otherwise
- A DNS lookup is required for each vhost.
- <P>
-
-<LI>A DNS lookup is always required for the main_server's
- <CODE>ServerName</CODE> (or to generate that if it isn't specified
- in the config).
- <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
- Host header was available to disambiguate the two.)
- <P>
-
-<LI>If a vhost that would otherwise be a name-vhost includes a
- <CODE>Port</CODE> statement that doesn't match the main_server
- <CODE>Port</CODE> then it will be considered an IP-based vhost.
- Then <CODE>find_virtual_server</CODE> will match it (because
- the ports associated with each address in the address set default
- to the port of the main_server) as the connection vhost. Then
- <CODE>check_hostalias</CODE> will refuse to check any other name-based
- vhost because of the port mismatch. The result is that the vhost
- will steal all hits going to the main_server address.
- <P>
-
-<LI>If two IP-based vhosts have an address in common, the vhost appearing
- later in the file is always matched. Such a thing might happen
- inadvertently. If the config has name-based vhosts and for some reason
- the main_server <CODE>ServerName</CODE> resolves to the wrong address
- then all the name-based vhosts will be parsed as ip-based vhosts.
- Then the last of them will steal all the hits.
- <P>
-
-<LI>The last name-based vhost in the config is always matched for any hit
- which doesn't match one of the other name-based vhosts.
-
-</UL>
-
-<H3><A NAME="whatworks">What Works</A></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 VirtualHost definitions.
-(This is to aid the readability of the configuration -- the post-config
-merging process makes it non-obvious that definitions mixed in around
-virtualhosts might affect all virtualhosts.)
-<P>
-
-<LI>Arrange your VirtualHosts such
-that all name-based virtual hosts come first, followed by IP-based
-virtual hosts, followed by any <SAMP>_default_</SAMP> virtual host
-<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>, "ServerPath /abc" should appear after
-"ServerPath /abcdef").
-<P>
-
-<LI>Do not use <EM>port-based</EM> vhosts in the same server as
-name-based vhosts. A loose definition for port-based is a vhost which
-is determined by the port on the server (<EM>i.e.</EM>, one server with
-ports 8000, 8080, and 80 - all of which have different configurations).
-<P>
-
-</UL>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
1.15 +432 -366 httpd-docs-1.3/htdocs/manual/vhosts/examples.html
Index: examples.html
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/vhosts/examples.html,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- examples.html 2001/01/11 01:29:12 1.14
+++ examples.html 2001/10/08 01:37:37 1.15
@@ -1,55 +1,67 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>VirtualHost Examples</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">Virtual Host examples for common setups</H1>
-
-
-<H2>Base configuration</H2>
-
-<UL>
-<LI><A HREF="#purename">Simple name-based vhosting</A>
-<LI><A HREF="#name">More complicated name-based vhosts</A>
-<LI><A HREF="#ip">IP-based vhosts</A>
-<LI><A HREF="#mixed">Mixed name-/IP-based vhosts</A>
-<LI><A HREF="#port">Port-based vhosts</A>
-</UL>
-
-<H2>Additional features</H2>
-
-<UL>
-<LI><A HREF="#default">Using <CODE>_default_</CODE> vhosts</A>
-<LI><A HREF="#migrate">Migrating a named-based vhost to an IP-based vhost</A>
-<LI><A HREF="#serverpath">Using the <CODE>ServerPath</CODE> directive</A>
-</UL>
-
-<HR>
-
-<H3><A NAME="purename">Simple name-based vhosting</A></H3>
-
-<UL>
-
-<LI><STRONG>Compatibility:</STRONG>
- This syntax was added in Apache 1.3.13.
-
-<LI><STRONG>Setup:</STRONG>
- The server machine has a primary name <SAMP>server.domain.tld</SAMP>.
- There are two aliases (CNAMEs) <SAMP>www.domain.tld</SAMP> and
- <SAMP>www.sub.domain.tld</SAMP> for the address <SAMP>server.domain.tld</SAMP>.
- <P>
- <STRONG>Server configuration:</STRONG>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
- <BLOCKQUOTE><PRE>
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta name="generator" content="HTML Tidy, see www.w3.org" />
+
+ <title>VirtualHost Examples</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">Virtual Host examples for common setups</h1>
+
+ <h2>Base configuration</h2>
+
+ <ul>
+ <li><a href="#purename">Simple name-based vhosting</a></li>
+
+ <li><a href="#name">More complicated name-based
+ vhosts</a></li>
+
+ <li><a href="#ip">IP-based vhosts</a></li>
+
+ <li><a href="#mixed">Mixed name-/IP-based vhosts</a></li>
+
+ <li><a href="#port">Port-based vhosts</a></li>
+ </ul>
+
+ <h2>Additional features</h2>
+
+ <ul>
+ <li><a href="#default">Using <code>_default_</code>
+ vhosts</a></li>
+
+ <li><a href="#migrate">Migrating a named-based vhost to an
+ IP-based vhost</a></li>
+
+ <li><a href="#serverpath">Using the <code>ServerPath</code>
+ directive</a></li>
+ </ul>
+ <hr />
+
+ <h3><a id="purename" name="purename">Simple name-based
+ vhosting</a></h3>
+
+ <ul>
+ <li><strong>Compatibility:</strong> This syntax was added in
+ Apache 1.3.13.</li>
+
+ <li>
+ <strong>Setup:</strong> The server machine has a primary
+ name <samp>server.domain.tld</samp>. There are two aliases
+ (CNAMEs) <samp>www.domain.tld</samp> and
+ <samp>www.sub.domain.tld</samp> for the address
+ <samp>server.domain.tld</samp>.
+
+ <p><strong>Server configuration:</strong></p>
+
+ <blockquote>
+<pre>
...
Port 80
ServerName server.domain.tld
@@ -67,31 +79,34 @@
ServerName www.sub.domain.tld
...
</VirtualHost>
- </PRE>
- The asterisks match all addresses, so the main server serves no
- requests. Due to the fact that <SAMP>www.domain.tld</SAMP> is first
- in the configuration file, it has the highest priority and can be
- seen as the <CITE>default</CITE> or <CITE>primary</CITE> server.
- </BLOCKQUOTE>
- <P>
-
-</UL>
-
-<HR>
-
-<H3><A NAME="name">More complicated name-based vhosts</A></H3>
-
-<UL>
-
-<LI><STRONG>Setup 1:</STRONG>
- The server machine has one IP address (<SAMP>111.22.33.44</SAMP>)
- which resolves to the name <SAMP>server.domain.tld</SAMP>.
- There are two aliases (CNAMEs) <SAMP>www.domain.tld</SAMP> and
- <SAMP>www.sub.domain.tld</SAMP> for the address <SAMP>111.22.33.44</SAMP>.
- <P>
- <STRONG>Server configuration:</STRONG>
+
+</pre>
+ The asterisks match all addresses, so the main server
+ serves no requests. Due to the fact that
+ <samp>www.domain.tld</samp> is first in the configuration
+ file, it has the highest priority and can be seen as the
+ <cite>default</cite> or <cite>primary</cite> server.
+ </blockquote>
+ </li>
+ </ul>
+ <hr />
+
+ <h3><a id="name" name="name">More complicated name-based
+ vhosts</a></h3>
+
+ <ul>
+ <li>
+ <strong>Setup 1:</strong> The server machine has one IP
+ address (<samp>111.22.33.44</samp>) which resolves to the
+ name <samp>server.domain.tld</samp>. There are two aliases
+ (CNAMEs) <samp>www.domain.tld</samp> and
+ <samp>www.sub.domain.tld</samp> for the address
+ <samp>111.22.33.44</samp>.
- <BLOCKQUOTE><PRE>
+ <p><strong>Server configuration:</strong></p>
+
+ <blockquote>
+<pre>
...
Port 80
ServerName server.domain.tld
@@ -109,34 +124,37 @@
ServerName www.sub.domain.tld
...
</VirtualHost>
- </PRE>
- Apart from <SAMP>localhost</SAMP> there are no unspecified
- addresses/ports, therefore the main server only serves
- <SAMP>localhost</SAMP> requests. Due to the fact
- that <SAMP>www.domain.tld</SAMP> has the highest priority
- it can be seen as the <CITE>default</CITE> or
- <CITE>primary</CITE> server.
- </BLOCKQUOTE>
- <P>
-
-<LI><STRONG>Setup 2:</STRONG>
- The server machine has two IP addresses (<SAMP>111.22.33.44</SAMP>
- and <SAMP>111.22.33.55</SAMP>)
- which resolve to the names <SAMP>server1.domain.tld</SAMP> and
- <SAMP>server2.domain.tld</SAMP> respectively.
- The alias <SAMP>www.domain.tld</SAMP> should be used for the
- main server which should also catch any unspecified addresses.
- We want to use a virtual host for the alias
- <SAMP>www.otherdomain.tld</SAMP> and another virtual host,
- with server name <SAMP>www.sub.domain.tld</SAMP>, should
- catch any request to hostnames of the form
- <SAMP>*.sub.domain.tld</SAMP>.
- The address <SAMP>111.22.33.55</SAMP> should be
- used for the virtual hosts.
- <P>
- <STRONG>Server configuration:</STRONG>
+
+</pre>
+ Apart from <samp>localhost</samp> there are no
+ unspecified addresses/ports, therefore the main server
+ only serves <samp>localhost</samp> requests. Due to the
+ fact that <samp>www.domain.tld</samp> has the highest
+ priority it can be seen as the <cite>default</cite> or
+ <cite>primary</cite> server.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Setup 2:</strong> The server machine has two IP
+ addresses (<samp>111.22.33.44</samp> and
+ <samp>111.22.33.55</samp>) which resolve to the names
+ <samp>server1.domain.tld</samp> and
+ <samp>server2.domain.tld</samp> respectively. The alias
+ <samp>www.domain.tld</samp> should be used for the main
+ server which should also catch any unspecified addresses.
+ We want to use a virtual host for the alias
+ <samp>www.otherdomain.tld</samp> and another virtual host,
+ with server name <samp>www.sub.domain.tld</samp>, should
+ catch any request to hostnames of the form
+ <samp>*.sub.domain.tld</samp>. The address
+ <samp>111.22.33.55</samp> should be used for the virtual
+ hosts.
+
+ <p><strong>Server configuration:</strong></p>
- <BLOCKQUOTE><PRE>
+ <blockquote>
+<pre>
...
Port 80
ServerName www.domain.tld
@@ -156,30 +174,35 @@
ServerAlias *.sub.domain.tld
...
</VirtualHost>
- </PRE>
- Any request to an address other than <SAMP>111.22.33.55</SAMP>
- will be served from the main server. A request to
- <SAMP>111.22.33.55</SAMP> with an unknown or no <CODE>Host:</CODE>
- header will be served from <SAMP>www.otherdomain.tld</SAMP>.
- </BLOCKQUOTE>
-
-<LI><STRONG>Setup 3:</STRONG>
- The server machine has two IP addresses (<SAMP>192.168.1.1</SAMP>
- and <SAMP>111.22.33.55</SAMP>). The machine is sitting between
- an internal (intranet) network and an external (internet) network.
- Outside of the network, the name <SAMP>server1.domain.tld</SAMP>
- resolves to the external address (<SAMP>111.22.33.55</SAMP>), but
- inside the network, that same name resolves to the internal
- address (<SAMP>192.168.1.1</SAMP>).<P>
-
- The server can be made to respond to internal and external
- requests with the same content, with just one <CODE>VirtualHost</CODE>
- section.
- <P>
+
+</pre>
+ Any request to an address other than
+ <samp>111.22.33.55</samp> will be served from the main
+ server. A request to <samp>111.22.33.55</samp> with an
+ unknown or no <code>Host:</code> header will be served
+ from <samp>www.otherdomain.tld</samp>.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Setup 3:</strong> The server machine has two IP
+ addresses (<samp>192.168.1.1</samp> and
+ <samp>111.22.33.55</samp>). The machine is sitting between
+ an internal (intranet) network and an external (internet)
+ network. Outside of the network, the name
+ <samp>server1.domain.tld</samp> resolves to the external
+ address (<samp>111.22.33.55</samp>), but inside the
+ network, that same name resolves to the internal address
+ (<samp>192.168.1.1</samp>).
+
+ <p>The server can be made to respond to internal and
+ external requests with the same content, with just one
+ <code>VirtualHost</code> section.</p>
- <STRONG>Server configuration:</STRONG>
+ <p><strong>Server configuration:</strong></p>
- <BLOCKQUOTE><PRE>
+ <blockquote>
+<pre>
...
NameVirtualHost 192.168.1.1
NameVirtualHost 111.22.33.55
@@ -190,23 +213,26 @@
ServerAlias server1
...
</VirtualHost>
- </PRE></BLOCKQUOTE>
-
- Now requests from both networks will be served from the same
- <CODE>VirtualHost</CODE>
-
-<LI><STRONG>Setup 4:</STRONG>
- You have multiple domains going to the same IP and also want
- to serve multiple ports. By defining the
- ports in the "NameVirtualHost" tag, you can allow this to
- work. If you try using <VirtualHost name:port> without the
- NameVirtualHost name:port or you try to use the Port
- directive, your configuration will not work.
- <P>
+
+</pre>
+ </blockquote>
+ Now requests from both networks will be served from the
+ same <code>VirtualHost</code>
+ </li>
+
+ <li>
+ <strong>Setup 4:</strong> You have multiple domains going
+ to the same IP and also want to serve multiple ports. By
+ defining the ports in the "NameVirtualHost" tag, you can
+ allow this to work. If you try using <VirtualHost
+ name:port> without the NameVirtualHost name:port or you
+ try to use the Port directive, your configuration will not
+ work.
- <STRONG>Server configuration:</STRONG>
+ <p><strong>Server configuration:</strong></p>
- <BLOCKQUOTE><PRE>
+ <blockquote>
+<pre>
...
NameVirtualHost 111.22.33.44:80
NameVirtualHost 111.22.33.44:8080
@@ -230,30 +256,31 @@
ServerName www.otherdomain.tld
DocumentRoot /www/otherdomain-8080
</VirtualHost>
-
- </PRE></BLOCKQUOTE>
-
-</UL>
-
-<HR>
-<H3><A NAME="ip">IP-based vhosts</A></H3>
-
-<UL>
-
-<LI><STRONG>Setup 1:</STRONG>
- The server machine has two IP addresses (<SAMP>111.22.33.44</SAMP>
- and <SAMP>111.22.33.55</SAMP>)
- which resolve to the names <SAMP>server.domain.tld</SAMP> and
- <SAMP>www.otherdomain.tld</SAMP> respectively.
- The hostname <SAMP>www.domain.tld</SAMP> is an alias (CNAME)
- for <SAMP>server.domain.tld</SAMP> and will represent the
- main server.
- <P>
- <STRONG>Server configuration:</STRONG>
+
+</pre>
+ </blockquote>
+ </li>
+ </ul>
+ <hr />
+
+ <h3><a id="ip" name="ip">IP-based vhosts</a></h3>
+
+ <ul>
+ <li>
+ <strong>Setup 1:</strong> The server machine has two IP
+ addresses (<samp>111.22.33.44</samp> and
+ <samp>111.22.33.55</samp>) which resolve to the names
+ <samp>server.domain.tld</samp> and
+ <samp>www.otherdomain.tld</samp> respectively. The hostname
+ <samp>www.domain.tld</samp> is an alias (CNAME) for
+ <samp>server.domain.tld</samp> and will represent the main
+ server.
+ <p><strong>Server configuration:</strong></p>
- <BLOCKQUOTE><PRE>
+ <blockquote>
+<pre>
...
Port 80
DocumentRoot /www/domain
@@ -264,20 +291,24 @@
ServerName www.otherdomain.tld
...
</VirtualHost>
- </PRE>
- <SAMP>www.otherdomain.tld</SAMP> can only be reached through the
- address <SAMP>111.22.33.55</SAMP>, while <SAMP>www.domain.tld</SAMP>
- can only be reached through <SAMP>111.22.33.44</SAMP>
- (which represents our main server).
- </BLOCKQUOTE>
- <P>
-
-<LI><STRONG>Setup 2:</STRONG>
- Same as setup 1, but we don't want to have a dedicated main server.
- <P>
- <STRONG>Server configuration:</STRONG>
+
+</pre>
+ <samp>www.otherdomain.tld</samp> can only be reached
+ through the address <samp>111.22.33.55</samp>, while
+ <samp>www.domain.tld</samp> can only be reached through
+ <samp>111.22.33.44</samp> (which represents our main
+ server).
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Setup 2:</strong> Same as setup 1, but we don't
+ want to have a dedicated main server.
- <BLOCKQUOTE><PRE>
+ <p><strong>Server configuration:</strong></p>
+
+ <blockquote>
+<pre>
...
Port 80
ServerName server.domain.tld
@@ -293,28 +324,31 @@
ServerName www.otherdomain.tld
...
</VirtualHost>
- </PRE>
- The main server can never catch a request, because all IP addresses
- of our machine are in use for IP-based virtual hosts
- (only <SAMP>localhost</SAMP> requests can hit the main server).
- </BLOCKQUOTE>
- <P>
-
-<LI><STRONG>Setup 3:</STRONG>
- The server machine has two IP addresses (<SAMP>111.22.33.44</SAMP>
- and <SAMP>111.22.33.55</SAMP>)
- which resolve to the names <SAMP>server.domain.tld</SAMP> and
- <SAMP>www-cache.domain.tld</SAMP> respectively.
- The hostname <SAMP>www.domain.tld</SAMP> is an alias (CNAME)
- for <SAMP>server.domain.tld</SAMP> and will represent the
- main server.
- <SAMP>www-cache.domain.tld</SAMP> will become our proxy-cache
- listening on port 8080, while the web server itself uses the default
- port 80.
- <P>
- <STRONG>Server configuration:</STRONG>
+
+</pre>
+ The main server can never catch a request, because all IP
+ addresses of our machine are in use for IP-based virtual
+ hosts (only <samp>localhost</samp> requests can hit the
+ main server).
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Setup 3:</strong> The server machine has two IP
+ addresses (<samp>111.22.33.44</samp> and
+ <samp>111.22.33.55</samp>) which resolve to the names
+ <samp>server.domain.tld</samp> and
+ <samp>www-cache.domain.tld</samp> respectively. The
+ hostname <samp>www.domain.tld</samp> is an alias (CNAME)
+ for <samp>server.domain.tld</samp> and will represent the
+ main server. <samp>www-cache.domain.tld</samp> will become
+ our proxy-cache listening on port 8080, while the web
+ server itself uses the default port 80.
+
+ <p><strong>Server configuration:</strong></p>
- <BLOCKQUOTE><PRE>
+ <blockquote>
+<pre>
...
Port 80
Listen 111.22.33.44:80
@@ -336,32 +370,38 @@
Allow from 111.22.33
</Directory>
</VirtualHost>
- </PRE>
- The main server can never catch a request, because all IP addresses
- (apart from <SAMP>localhost</SAMP>) of our machine are in use for IP-based
- virtual hosts. The web server can only be reached on the first address
- through port 80 and the proxy only on the second address through port 8080.
- </BLOCKQUOTE>
-</UL>
-
-<HR>
-
-<H3><A NAME="mixed">Mixed name-/IP-based vhosts</A></H3>
-
-<UL>
-
-<LI><STRONG>Setup:</STRONG>
- The server machine has three IP addresses (<SAMP>111.22.33.44</SAMP>,
- <SAMP>111.22.33.55</SAMP> and <SAMP>111.22.33.66</SAMP>)
- which resolve to the names <SAMP>server.domain.tld</SAMP>,
- <SAMP>www.otherdomain1.tld</SAMP> and <SAMP>www.otherdomain2.tld</SAMP>
- respectively.
- The address <SAMP>111.22.33.44</SAMP> should we used for a couple
- of name-based vhosts and the other addresses for IP-based vhosts.
- <P>
- <STRONG>Server configuration:</STRONG>
+
+</pre>
+ The main server can never catch a request, because all IP
+ addresses (apart from <samp>localhost</samp>) of our
+ machine are in use for IP-based virtual hosts. The web
+ server can only be reached on the first address through
+ port 80 and the proxy only on the second address through
+ port 8080.
+ </blockquote>
+ </li>
+ </ul>
+ <hr />
+
+ <h3><a id="mixed" name="mixed">Mixed name-/IP-based
+ vhosts</a></h3>
+
+ <ul>
+ <li>
+ <strong>Setup:</strong> The server machine has three IP
+ addresses (<samp>111.22.33.44</samp>,
+ <samp>111.22.33.55</samp> and <samp>111.22.33.66</samp>)
+ which resolve to the names <samp>server.domain.tld</samp>,
+ <samp>www.otherdomain1.tld</samp> and
+ <samp>www.otherdomain2.tld</samp> respectively. The address
+ <samp>111.22.33.44</samp> should we used for a couple of
+ name-based vhosts and the other addresses for IP-based
+ vhosts.
+
+ <p><strong>Server configuration:</strong></p>
- <BLOCKQUOTE><PRE>
+ <blockquote>
+<pre>
...
Port 80
ServerName server.domain.tld
@@ -397,26 +437,28 @@
ServerName www.otherdomain2.tld
...
</VirtualHost>
- </PRE></BLOCKQUOTE>
-
-</UL>
-
-<HR>
-
-<H3><A NAME="port">Port-based vhosts</A></H3>
-
-<UL>
+
+</pre>
+ </blockquote>
+ </li>
+ </ul>
+ <hr />
+
+ <h3><a id="port" name="port">Port-based vhosts</a></h3>
+
+ <ul>
+ <li>
+ <strong>Setup:</strong> The server machine has one IP
+ address (<samp>111.22.33.44</samp>) which resolves to the
+ name <samp>www.domain.tld</samp>. If we don't have the
+ option to get another address or alias for our server we
+ can use port-based vhosts if we need a virtual host with a
+ different configuration.
-<LI><STRONG>Setup:</STRONG>
- The server machine has one IP address (<SAMP>111.22.33.44</SAMP>)
- which resolves to the name <SAMP>www.domain.tld</SAMP>.
- If we don't have the option to get another address or alias
- for our server we can use port-based vhosts if we need
- a virtual host with a different configuration.
- <P>
- <STRONG>Server configuration:</STRONG>
+ <p><strong>Server configuration:</strong></p>
- <BLOCKQUOTE><PRE>
+ <blockquote>
+<pre>
...
Listen 80
Listen 8080
@@ -427,56 +469,64 @@
DocumentRoot /www/domain2
...
</VirtualHost>
- </PRE>
- A request to <SAMP>www.domain.tld</SAMP> on port 80 is served
- from the main server and a request to port 8080 is served from
- the virtual host.
- </BLOCKQUOTE>
-</UL>
-
-<HR>
-
-<H3><A NAME="default">Using <CODE>_default_</CODE> vhosts</A></H3>
-
-<UL>
-
-<LI><STRONG>Setup 1:</STRONG>
- Catching <EM>every</EM> request to any unspecified IP address and port,
- <EM>i.e.</EM>, an address/port combination that is not used for any other
- virtual host.
- <P>
- <STRONG>Server configuration:</STRONG>
+
+</pre>
+ A request to <samp>www.domain.tld</samp> on port 80 is
+ served from the main server and a request to port 8080 is
+ served from the virtual host.
+ </blockquote>
+ </li>
+ </ul>
+ <hr />
+
+ <h3><a id="default" name="default">Using <code>_default_</code>
+ vhosts</a></h3>
+
+ <ul>
+ <li>
+ <strong>Setup 1:</strong> Catching <em>every</em> request
+ to any unspecified IP address and port, <em>i.e.</em>, an
+ address/port combination that is not used for any other
+ virtual host.
+
+ <p><strong>Server configuration:</strong></p>
- <BLOCKQUOTE><PRE>
+ <blockquote>
+<pre>
...
<VirtualHost _default_:*>
DocumentRoot /www/default
...
</VirtualHost>
- </PRE>
- Using such a default vhost with a wildcard port effectively
- prevents any request going to the main server.<BR>
- A default vhost never serves a request that was sent to an
- address/port that is used for name-based vhosts. If the request
- contained an unknown or no <CODE>Host:</CODE> header it is
- always served from the primary name-based vhost (the
- vhost for that address/port appearing first in the configuration
- file).<BR>
- You can use
- <A HREF="../mod/mod_alias.html#aliasmatch"><CODE>AliasMatch</CODE></A>
- or
- <A HREF="../mod/mod_rewrite.html#RewriteRule"><CODE>RewriteRule</CODE></A>
- to rewrite any request to a single information page (or script).
- </BLOCKQUOTE>
- <P>
-
-<LI><STRONG>Setup 2:</STRONG>
- Same as setup 1, but the server listens on several ports and
- we want to use a second <CODE>_default_</CODE> vhost for port 80.
- <P>
- <STRONG>Server configuration:</STRONG>
+
+</pre>
+ Using such a default vhost with a wildcard port
+ effectively prevents any request going to the main
+ server.<br />
+ A default vhost never serves a request that was sent to
+ an address/port that is used for name-based vhosts. If
+ the request contained an unknown or no <code>Host:</code>
+ header it is always served from the primary name-based
+ vhost (the vhost for that address/port appearing first in
+ the configuration file).<br />
+ You can use <a
+ href="../mod/mod_alias.html#aliasmatch"><code>AliasMatch</code></a>
+ or <a
+ href="../mod/mod_rewrite.html#RewriteRule"><code>RewriteRule</code></a>
+ to rewrite any request to a single information page (or
+ script).
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Setup 2:</strong> Same as setup 1, but the server
+ listens on several ports and we want to use a second
+ <code>_default_</code> vhost for port 80.
- <BLOCKQUOTE><PRE>
+ <p><strong>Server configuration:</strong></p>
+
+ <blockquote>
+<pre>
...
<VirtualHost _default_:80>
DocumentRoot /www/default80
@@ -487,52 +537,59 @@
DocumentRoot /www/default
...
</VirtualHost>
- </PRE>
- The default vhost for port 80 (which <EM>must</EM> appear before
- any default vhost with a wildcard port) catches all requests that
- were sent to an unspecified IP address. The main server is
- never used to serve a request.
- </BLOCKQUOTE>
- <P>
-
-<LI><STRONG>Setup 3:</STRONG>
- We want to have a default vhost for port 80, but no other default vhosts.
- <P>
- <STRONG>Server configuration:</STRONG>
+
+</pre>
+ The default vhost for port 80 (which <em>must</em> appear
+ before any default vhost with a wildcard port) catches
+ all requests that were sent to an unspecified IP address.
+ The main server is never used to serve a request.
+ </blockquote>
+ </li>
+
+ <li>
+ <strong>Setup 3:</strong> We want to have a default vhost
+ for port 80, but no other default vhosts.
- <BLOCKQUOTE><PRE>
+ <p><strong>Server configuration:</strong></p>
+
+ <blockquote>
+<pre>
...
<VirtualHost _default_:80>
DocumentRoot /www/default
...
</VirtualHost>
- </PRE>
- A request to an unspecified address on port 80 is served from the
- default vhost any other request to an unspecified address and port
- is served from the main server.
- </BLOCKQUOTE>
-
-</UL>
-
-<HR>
-
-<H3><A NAME="migrate">Migrating a name-based vhost to an IP-based vhost</A></H3>
-
-<UL>
-
-<LI><STRONG>Setup:</STRONG>
- The name-based vhost with the hostname
- <SAMP>www.otherdomain.tld</SAMP> (from our <A HREF="#name">name-based</A>
- example, setup 2) should get its own IP address.
- To avoid problems with name servers or proxies who cached the old
- IP address for the name-based vhost we want to provide both variants
- during a migration phase.<BR>
- The solution is easy, because we can simply add the new IP address
- (<SAMP>111.22.33.66</SAMP>) to the <CODE>VirtualHost</CODE> directive.
- <P>
- <STRONG>Server configuration:</STRONG>
+
+</pre>
+ A request to an unspecified address on port 80 is served
+ from the default vhost any other request to an
+ unspecified address and port is served from the main
+ server.
+ </blockquote>
+ </li>
+ </ul>
+ <hr />
+
+ <h3><a id="migrate" name="migrate">Migrating a name-based vhost
+ to an IP-based vhost</a></h3>
+
+ <ul>
+ <li>
+ <strong>Setup:</strong> The name-based vhost with the
+ hostname <samp>www.otherdomain.tld</samp> (from our <a
+ href="#name">name-based</a> example, setup 2) should get
+ its own IP address. To avoid problems with name servers or
+ proxies who cached the old IP address for the name-based
+ vhost we want to provide both variants during a migration
+ phase.<br />
+ The solution is easy, because we can simply add the new IP
+ address (<samp>111.22.33.66</samp>) to the
+ <code>VirtualHost</code> directive.
- <BLOCKQUOTE><PRE>
+ <p><strong>Server configuration:</strong></p>
+
+ <blockquote>
+<pre>
...
Port 80
ServerName www.domain.tld
@@ -552,31 +609,35 @@
ServerAlias *.sub.domain.tld
...
</VirtualHost>
- </PRE>
- The vhost can now be accessed through the new address (as an IP-based
- vhost) and through the old address (as a name-based vhost).
- </BLOCKQUOTE>
-
-</UL>
-
-<HR>
-
-<H3><A NAME="serverpath">Using the <CODE>ServerPath</CODE> directive</A></H3>
-
-<UL>
-
-<LI><STRONG>Setup:</STRONG>
- We have a server with two name-based vhosts. In order to match the correct
- virtual host a client must send the correct <CODE>Host:</CODE> header.
- Old HTTP/1.0 clients do not send such a header and Apache has no clue
- what vhost the client tried to reach (and serves the request from
- the primary vhost). To provide as much backward compatibility
- as possible we create a primary vhost which returns a single page
- containing links with an URL prefix to the name-based virtual hosts.
- <P>
- <STRONG>Server configuration:</STRONG>
+
+</pre>
+ The vhost can now be accessed through the new address (as
+ an IP-based vhost) and through the old address (as a
+ name-based vhost).
+ </blockquote>
+ </li>
+ </ul>
+ <hr />
+
+ <h3><a id="serverpath" name="serverpath">Using the
+ <code>ServerPath</code> directive</a></h3>
+
+ <ul>
+ <li>
+ <strong>Setup:</strong> We have a server with two
+ name-based vhosts. In order to match the correct virtual
+ host a client must send the correct <code>Host:</code>
+ header. Old HTTP/1.0 clients do not send such a header and
+ Apache has no clue what vhost the client tried to reach
+ (and serves the request from the primary vhost). To provide
+ as much backward compatibility as possible we create a
+ primary vhost which returns a single page containing links
+ with an URL prefix to the name-based virtual hosts.
- <BLOCKQUOTE><PRE>
+ <p><strong>Server configuration:</strong></p>
+
+ <blockquote>
+<pre>
...
NameVirtualHost 111.22.33.44
@@ -605,26 +666,31 @@
RewriteRule ^(/sub2/.*) /www/subdomain$1
...
</VirtualHost>
- </PRE>
- Due to the <A HREF="../mod/core.html#serverpath"><CODE>ServerPath</CODE></A>
- directive a request to the
- URL <SAMP>http://www.sub1.domain.tld/sub1/</SAMP> is <EM>always</EM>
- served from the sub1-vhost. <BR>
- A request to the URL <SAMP>http://www.sub1.domain.tld/</SAMP>
- is only served from the sub1-vhost if the client sent a correct
- <CODE>Host:</CODE> header.
- If no <CODE>Host:</CODE> header is sent the client gets the
- information page from the primary host.<BR>
- Please note that there is one oddity: A request to
- <SAMP>http://www.sub2.domain.tld/sub1/</SAMP> is also served from
- the sub1-vhost if the client sent no <CODE>Host:</CODE> header. <BR>
- The <CODE>RewriteRule</CODE> directives are used to make sure that
- a client which sent a correct <CODE>Host:</CODE> header can use
- both URL variants, <EM>i.e.</EM>, with or without URL prefix.
- </BLOCKQUOTE>
-
-</UL>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+
+</pre>
+ Due to the <a
+ href="../mod/core.html#serverpath"><code>ServerPath</code></a>
+ directive a request to the URL
+ <samp>http://www.sub1.domain.tld/sub1/</samp> is
+ <em>always</em> served from the sub1-vhost.<br />
+ A request to the URL
+ <samp>http://www.sub1.domain.tld/</samp> is only served
+ from the sub1-vhost if the client sent a correct
+ <code>Host:</code> header. If no <code>Host:</code>
+ header is sent the client gets the information page from
+ the primary host.<br />
+ Please note that there is one oddity: A request to
+ <samp>http://www.sub2.domain.tld/sub1/</samp> is also
+ served from the sub1-vhost if the client sent no
+ <code>Host:</code> header.<br />
+ The <code>RewriteRule</code> directives are used to make
+ sure that a client which sent a correct
+ <code>Host:</code> header can use both URL variants,
+ <em>i.e.</em>, with or without URL prefix.
+ </blockquote>
+ </li>
+ </ul>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
1.4 +71 -57 httpd-docs-1.3/htdocs/manual/vhosts/fd-limits.html
Index: fd-limits.html
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/htdocs/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/10/08 01:37:37 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.4 +17 -6 httpd-docs-1.3/htdocs/manual/vhosts/footer.html
Index: footer.html
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/vhosts/footer.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- footer.html 1997/11/12 13:54:26 1.3
+++ footer.html 2001/10/08 01:37:37 1.4
@@ -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 1.3
-</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 1.3</h3>
+ <a href="./"><img src="../images/index.gif" alt="Index" /></a>
+ <a href="../"><img src="../images/home.gif" alt="Home" /></a>
+ </body>
+</html>
+
1.3 +19 -6 httpd-docs-1.3/htdocs/manual/vhosts/header.html
Index: header.html
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/vhosts/header.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- header.html 1997/11/12 13:53:14 1.2
+++ header.html 2001/10/08 01:37:37 1.3
@@ -1,6 +1,19 @@
-<DIV ALIGN="CENTER">
- <IMG SRC="../images/sub.gif" ALT="[APACHE DOCUMENTATION]">
- <H3>
- Apache HTTP Server Version 1.3
- </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 1.3</h3>
+ </div>
+ </body>
+</html>
+
1.10 +164 -163 httpd-docs-1.3/htdocs/manual/vhosts/host.html
Index: host.html
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/vhosts/host.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- host.html 2000/09/12 02:29:17 1.9
+++ host.html 2001/10/08 01:37:37 1.10
@@ -1,172 +1,173 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>Apache non-IP 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 non-IP Virtual Hosts</H1>
-
-<STRONG>See Also:</STRONG>
-<A HREF="virtual-host.html">Virtual Host Support</A>
-
-<HR>
-
-<H2>What is a Virtual Host</H2>
-
-<P>The "Virtual Host" 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
-<CODE>www.company1.com</CODE> and <CODE>www.company2.com</CODE>,
-without requiring the user to know any extra path information.</P>
-
-<P>Apache was one of the first servers to support virtual hosts right
-out of the box, but since the base <CODE>HTTP</CODE> (HyperText
-Transport Protocol) standard does not allow any method for the server
-to determine the hostname it is being addressed as, Apache's virtual
-host support has required a separate IP address for each
-server. Documentation on using this approach (which still works very
-well) <A HREF="virtual-host.html">is available</A>.
-
-<P>While the approach described above works, with the available IP
-address space growing smaller, and the number of domains increasing,
-it is not the most elegant solution, and is hard to implement on some
-machines. The <CODE>HTTP/1.1</CODE> protocol contains 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 traditional
-IP-address-per-hostname method.</P>
-
-<P>The benefits of using the new virtual host support is a practically
-unlimited number of servers, ease of configuration and use, and
-requires no additional hardware or software. The main disadvantage is
-that the user's browser must support this part of the protocol. The
-latest versions of many browsers (including Netscape Navigator 2.0 and
-later) do, but many browsers, especially older ones, do not. This can
-cause problems, although a possible solution is addressed below.</P>
-
-<H2>Using non-IP Virtual Hosts</H2>
-
-<P>Using the new virtual hosts is quite easy, and superficially looks
-like the old method. 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>
+<!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 non-IP 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 non-IP Virtual Hosts</h1>
+ <strong>See Also:</strong> <a href="virtual-host.html">Virtual
+ Host Support</a>
+ <hr />
+
+ <h2>What is a Virtual Host</h2>
+
+ <p>The "Virtual Host" 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 <code>www.company1.com</code> and
+ <code>www.company2.com</code>, without requiring the user to
+ know any extra path information.</p>
+
+ <p>Apache was one of the first servers to support virtual hosts
+ right out of the box, but since the base <code>HTTP</code>
+ (HyperText Transport Protocol) standard does not allow any
+ method for the server to determine the hostname it is being
+ addressed as, Apache's virtual host support has required a
+ separate IP address for each server. Documentation on using
+ this approach (which still works very well) <a
+ href="virtual-host.html">is available</a>.</p>
+
+ <p>While the approach described above works, with the available
+ IP address space growing smaller, and the number of domains
+ increasing, it is not the most elegant solution, and is hard to
+ implement on some machines. The <code>HTTP/1.1</code> protocol
+ contains 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 traditional IP-address-per-hostname method.</p>
+
+ <p>The benefits of using the new virtual host support is a
+ practically unlimited number of servers, ease of configuration
+ and use, and requires no additional hardware or software. The
+ main disadvantage is that the user's browser must support this
+ part of the protocol. The latest versions of many browsers
+ (including Netscape Navigator 2.0 and later) do, but many
+ browsers, especially older ones, do not. This can cause
+ problems, although a possible solution is addressed below.</p>
+
+ <h2>Using non-IP Virtual Hosts</h2>
+
+ <p>Using the new virtual hosts is quite easy, and superficially
+ looks like the old method. 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>
<VirtualHost www.apache.org>
ServerName www.apache.org
DocumentRoot /usr/web/apache
</VirtualHost>
-</PRE>
-
-<P>Of course, any additional directives can (and should) be placed
-into the <CODE><VirtualHost></CODE> section. To make this work,
-all that is needed is to make sure that the <CODE>www.apache.org</CODE>
-DNS entry points to the same IP address as the main
-server. Optionally, you could simply use that IP address in the
-<VirtualHost> entry.</P>
-
-<P>Additionally, many servers may wish to be accessible by more than
-one name. For example, the Apache server might want to be accessible
-as <CODE>apache.org</CODE>, or <CODE>ftp.apache.org</CODE>, assuming
-the IP addresses pointed to the same server. In fact, one might want it
-so that all addresses at <CODE>apache.org</CODE> were picked up by the
-server. This is possible with the <CODE>ServerAlias</CODE>
-directive, placed inside the <VirtualHost> section. For
-example:</P>
+</pre>
-<PRE>
+ <p>Of course, any additional directives can (and should) be
+ placed into the <code><VirtualHost></code> section. To
+ make this work, all that is needed is to make sure that the
+ <code>www.apache.org</code> DNS entry points to the same IP
+ address as the main server. Optionally, you could simply use
+ that IP address in the <VirtualHost> entry.</p>
+
+ <p>Additionally, many servers may wish to be accessible by more
+ than one name. For example, the Apache server might want to be
+ accessible as <code>apache.org</code>, or
+ <code>ftp.apache.org</code>, assuming the IP addresses pointed
+ to the same server. In fact, one might want it so that all
+ addresses at <code>apache.org</code> were picked up by the
+ server. This is possible with the <code>ServerAlias</code>
+ directive, placed inside the <VirtualHost> section. For
+ example:</p>
+<pre>
ServerAlias apache.org *.apache.org
-</PRE>
-
-<P>Note that you can use <CODE>*</CODE> and <CODE>?</CODE> as wild-card
-characters.</P>
+</pre>
-<P>You also might need ServerAlias 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.physics" then you will need to add
-<CODE>ServerAlias www www.physics</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.</P>
-
-<H2>Security Considerations</H2>
-
-Apache allows all virtual hosts to be made accessible via the
-<CODE>Host:</CODE> header through all IP interfaces, even those which
-are configured to use different IP interfaces. For example, if the
-configuration for <CODE>www.foo.com</CODE> contained a virtual host
-section for <CODE>www.bar.com</CODE>, and <CODE>www.bar.com</CODE> was
-a separate IP interface, such that
-non-<CODE>Host:</CODE>-header-supporting browsers can use it, as
-before with Apache 1.0. If a request is made to
-<CODE>www.foo.com</CODE> and the request includes the header
-<CODE>Host: www.bar.com</CODE>, a page from <CODE>www.bar.com</CODE>
-will be sent.
-
-<P>
-
-This is a security concern if you are controlling access to a
-particular server based on IP-layer controls, such as from within a
-firewall or router. Let's say <CODE>www.bar.com</CODE> in the above
-example was instead an intra-net server called
-<CODE>private.foo.com</CODE>, and the router used by foo.com only let
-internal users access <CODE>private.foo.com</CODE>. Obviously,
-<CODE>Host:</CODE> header functionality now allows someone who has
-access to <CODE>www.foo.com</CODE> to get
-<CODE>private.foo.com</CODE>, if they send a <CODE>Host:
-private.foo.com</CODE> header. It is important to note that this
-condition exists only if you only implement this policy at the IP
-layer - all security controls used by Apache (<EM>i.e.</EM>, <A
-HREF="../mod/mod_access.html">Allow, Deny from,</A> <EM>etc.</EM>) are
-consistently respected.
-
-<H2>Compatibility with Older Browsers</H2>
-
-<P>As mentioned earlier, a majority of browsers do not send the
-required data for the new virtual hosts to work properly. These
-browsers will always be sent to the main server's pages. There is a
-workaround, albeit a slightly cumbersome one:</P>
-
-<P>To continue the <CODE>www.apache.org</CODE> example (Note: Apache's
-web server does not actually function in this manner), we might use the
-new <CODE>ServerPath</CODE> directive in the <CODE>www.apache.org</CODE>
-virtual host, for example:
+ <p>Note that you can use <code>*</code> and <code>?</code> as
+ wild-card characters.</p>
-<PRE>
+ <p>You also might need ServerAlias 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.physics"
+ then you will need to add <code>ServerAlias www
+ www.physics</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.</p>
+
+ <h2>Security Considerations</h2>
+ Apache allows all virtual hosts to be made accessible via the
+ <code>Host:</code> header through all IP interfaces, even those
+ which are configured to use different IP interfaces. For
+ example, if the configuration for <code>www.foo.com</code>
+ contained a virtual host section for <code>www.bar.com</code>,
+ and <code>www.bar.com</code> was a separate IP interface, such
+ that non-<code>Host:</code>-header-supporting browsers can use
+ it, as before with Apache 1.0. If a request is made to
+ <code>www.foo.com</code> and the request includes the header
+ <code>Host: www.bar.com</code>, a page from
+ <code>www.bar.com</code> will be sent.
+
+ <p>This is a security concern if you are controlling access to
+ a particular server based on IP-layer controls, such as from
+ within a firewall or router. Let's say <code>www.bar.com</code>
+ in the above example was instead an intra-net server called
+ <code>private.foo.com</code>, and the router used by foo.com
+ only let internal users access <code>private.foo.com</code>.
+ Obviously, <code>Host:</code> header functionality now allows
+ someone who has access to <code>www.foo.com</code> to get
+ <code>private.foo.com</code>, if they send a <code>Host:
+ private.foo.com</code> header. It is important to note that
+ this condition exists only if you only implement this policy at
+ the IP layer - all security controls used by Apache
+ (<em>i.e.</em>, <a href="../mod/mod_access.html">Allow, Deny
+ from,</a> <em>etc.</em>) are consistently respected.</p>
+
+ <h2>Compatibility with Older Browsers</h2>
+
+ <p>As mentioned earlier, a majority of browsers do not send the
+ required data for the new virtual hosts to work properly. These
+ browsers will always be sent to the main server's pages. There
+ is a workaround, albeit a slightly cumbersome one:</p>
+
+ <p>To continue the <code>www.apache.org</code> example (Note:
+ Apache's web server does not actually function in this manner),
+ we might use the new <code>ServerPath</code> directive in the
+ <code>www.apache.org</code> virtual host, for example:</p>
+<pre>
ServerPath /apache
-</PRE>
-<P>What does this mean? It means that a request for any file beginning
-with "<CODE>/apache</CODE>" will be looked for in the Apache
-docs. This means that the pages can be accessed as
-<CODE>http://www.apache.org/apache/</CODE> for all browsers, although
-new browsers can also access it as
-<CODE>http://www.apache.org/</CODE>.</P>
-
-<P>In order to make this work, put a link on your main server's page
-to <CODE>http://www.apache.org/apache/</CODE> (Note: Do not use
-<CODE>http://www.apache.org/</CODE> - this would create an endless
-loop). Then, in the virtual host's pages, be sure to use either purely
-relative links (<EM>e.g.</EM>, "<CODE>file.html</CODE>" or
-"<CODE>../icons/image.gif</CODE>" or links containing the prefacing
-<CODE>/apache/</CODE>
-(<EM>e.g.</EM>, "<CODE>http://www.apache.org/apache/file.html</CODE>" or
-"<CODE>/apache/docs/1.1/index.html</CODE>").</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. When
-a new browser contacts <CODE>http://www.apache.org/</CODE>, they will
-be directly taken to the Apache pages. Older browsers will be able to
-click on the link from the main server, go to
-<CODE>http://www.apache.org/apache/</CODE>, and then access the
-pages.</P>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+</pre>
+
+ <p>What does this mean? It means that a request for any file
+ beginning with "<code>/apache</code>" will be looked for in the
+ Apache docs. This means that the pages can be accessed as
+ <code>http://www.apache.org/apache/</code> for all browsers,
+ although new browsers can also access it as
+ <code>http://www.apache.org/</code>.</p>
+
+ <p>In order to make this work, put a link on your main server's
+ page to <code>http://www.apache.org/apache/</code> (Note: Do
+ not use <code>http://www.apache.org/</code> - this would create
+ an endless loop). Then, in the virtual host's pages, be sure to
+ use either purely relative links (<em>e.g.</em>,
+ "<code>file.html</code>" or "<code>../icons/image.gif</code>"
+ or links containing the prefacing <code>/apache/</code>
+ (<em>e.g.</em>,
+ "<code>http://www.apache.org/apache/file.html</code>" or
+ "<code>/apache/docs/1.1/index.html</code>").</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. When a new browser
+ contacts <code>http://www.apache.org/</code>, they will be
+ directly taken to the Apache pages. Older browsers will be able
+ to click on the link from the main server, go to
+ <code>http://www.apache.org/apache/</code>, and then access the
+ pages.</p>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
+
1.8 +84 -65 httpd-docs-1.3/htdocs/manual/vhosts/index.html.en
Index: index.html.en
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/vhosts/index.html.en,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- index.html.en 2000/09/13 20:00:48 1.7
+++ index.html.en 2001/10/08 01:37:37 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"><VirtualHost></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"><VirtualHost></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.2 +3 -0 httpd-docs-1.3/htdocs/manual/vhosts/index.html.html
Index: index.html.html
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/vhosts/index.html.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- index.html.html 2001/02/10 21:59:15 1.1
+++ index.html.html 2001/10/08 01:37:37 1.2
@@ -1 +1,4 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!--#include virtual="index.html.en" -->
+
1.8 +122 -117 httpd-docs-1.3/htdocs/manual/vhosts/ip-based.html
Index: ip-based.html
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/htdocs/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:03 1.7
+++ ip-based.html 2001/10/08 01:37:37 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>
<VirtualHost www.smallco.com>
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
</VirtualHost>
-</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-docs-1.3/htdocs/manual/vhosts/mass.html
Index: mass.html
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/htdocs/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:15:27 1.5
+++ mass.html 2001/10/08 01:37:37 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><VirtualHost></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><VirtualHost></code> sections that are
+ substantially the same, for example:</p>
+<pre>
NameVirtualHost 111.22.33.44
<VirtualHost 111.22.33.44>
- 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
</VirtualHost>
<VirtualHost 111.22.33.44>
- 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
</VirtualHost>
# blah blah blah
<VirtualHost 111.22.33.44>
- 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
</VirtualHost>
-</PRE>
-</P>
-
-<P>The basic idea is to replace all of the static
-<CODE><VirtualHost></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><VirtualHost></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><VirtualHost></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><VirtualHost></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><VirtualHost></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><VirtualHost></code> configuration sections.</p>
+<pre>
UseCanonicalName Off
LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
<Directory /www/commercial>
- Options FollowSymLinks
- AllowOverride All
+ Options FollowSymLinks
+ AllowOverride All
</Directory>
<Directory /www/homepages>
- Options FollowSymLinks
- AllowOverride None
+ Options FollowSymLinks
+ AllowOverride None
</Directory>
<VirtualHost 111.22.33.44>
- 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
</VirtualHost>
<VirtualHost 111.22.33.45>
- 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/
</VirtualHost>
-</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
<Directory /www/hosts>
- # 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
</Directory>
# 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.16 +154 -150 httpd-docs-1.3/htdocs/manual/vhosts/name-based.html.en
Index: name-based.html.en
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/vhosts/name-based.html.en,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- name-based.html.en 2000/10/19 23:32:55 1.15
+++ name-based.html.en 2001/10/08 01:37:37 1.16
@@ -1,62 +1,63 @@
-<!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.</P>
-
-<P>For example, suppose that both <SAMP>www.domain.tld</SAMP> and
-<SAMP>www.otherdomain.tld</SAMP> point at the IP address
-<SAMP>111.22.33.44</SAMP>. 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.</p>
+
+ <p>For example, suppose that both <samp>www.domain.tld</samp>
+ and <samp>www.otherdomain.tld</samp> point at the IP address
+ <samp>111.22.33.44</samp>. 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 111.22.33.44
<VirtualHost 111.22.33.44>
@@ -68,76 +69,77 @@
ServerName www.otherdomain.tld
DocumentRoot /www/otherdomain
</VirtualHost>
-</PRE>
+</pre>
-<P>Of course, any additional directives can (and should) be placed
-into the <CODE><VirtualHost></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 IP address <SAMP>111.22.33.44</SAMP></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 <VirtualHost>s. The "main server" will
-<STRONG>never</STRONG> be served from the specified IP address.
-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 <VirtualHost> section for
-<EM>every</EM> server (hostname) you want to maintain on your server.
-
-<P>In Apache 1.3.13 and later you can specify the
-<CODE>NameVirtualHost</CODE> IP address as the wildcard <CODE>*</CODE>
-which matches any IP address not covered by more specific virtual
-host directive(s). This is useful for configuring a server whose IP
-address you do not know in advance, e.g. because it has a dynamically
-configured IP address or because it is part of a load-balanced cluster
-in which every machine shares the same configuration file.
-</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 <VirtualHost> section. For
-example:</P>
-
-<PRE>
+ <p>Of course, any additional directives can (and should) be
+ placed into the <code><VirtualHost></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 IP address
+ <samp>111.22.33.44</samp></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
+ <VirtualHost>s. The "main server" will
+ <strong>never</strong> be served from the specified IP address.
+ 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
+ <VirtualHost> section for <em>every</em> server
+ (hostname) you want to maintain on your server.</p>
+
+ <p>In Apache 1.3.13 and later you can specify the
+ <code>NameVirtualHost</code> IP address as the wildcard
+ <code>*</code> which matches any IP address not covered by more
+ specific virtual host directive(s). This is useful for
+ configuring a server whose IP address you do not know in
+ advance, e.g. because it has a dynamically configured IP
+ address or because it is part of a load-balanced cluster in
+ which every machine shares the same configuration file.</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 <VirtualHost> 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
<VirtualHost 111.22.33.44>
@@ -145,31 +147,33 @@
ServerPath /domain
DocumentRoot /web/domain
</VirtualHost>
-</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>
1.2 +3 -0 httpd-docs-1.3/htdocs/manual/vhosts/name-based.html.html
Index: name-based.html.html
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/vhosts/name-based.html.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- name-based.html.html 2001/05/17 03:45:30 1.1
+++ name-based.html.html 2001/10/08 01:37:37 1.2
@@ -1 +1,4 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!--#include virtual="name-based.html.en" -->
+
1.6 +373 -383 httpd-docs-1.3/htdocs/manual/vhosts/vhosts-in-depth.html
Index: vhosts-in-depth.html
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/vhosts/vhosts-in-depth.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- vhosts-in-depth.html 1998/08/19 06:16:58 1.5
+++ vhosts-in-depth.html 2001/10/08 01:37:37 1.6
@@ -1,97 +1,96 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
-<HTML><HEAD>
-<TITLE>An In-Depth Discussion of VirtualHost 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 VirtualHost Matching</H1>
-
-<P>This is a very rough document that was probably out of date the moment
-it was written. It attempts to explain exactly what the code does when
-deciding what virtual host to serve a hit from. It's provided on the
-assumption that something is better than nothing. The server version
-under discussion is Apache 1.2.
-
-<P>If you just want to "make it work" without understanding
-how, there's a <A HREF="#whatworks">What Works</A> section at the bottom.
-
-<H3>Config File Parsing</H3>
-
-<P>There is a main_server which consists of all the definitions appearing
-outside of <CODE>VirtualHost</CODE> sections. There are virtual servers,
-called <EM>vhosts</EM>, which are defined by
-<A
- HREF="../mod/core.html#virtualhost"
-><SAMP>VirtualHost</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>ServerName</CODE>,
-<CODE>ServerPath</CODE>, or <CODE>ServerAlias</CODE>.
-
-<P>In the absence of any
-<A
- HREF="../mod/core.html#listen"
-><SAMP>Listen</SAMP></A>
-directives, the (final if there
-are multiple) <CODE>Port</CODE> directive in the main_server indicates
-which port httpd will listen on.
-
-<P> The <CODE>Port</CODE> and <CODE>ServerName</CODE> directives for
-any server main or virtual are used when generating URLs such as during
-redirects.
-
-<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> The magic <CODE>_default_</CODE> address has significance during
-the matching algorithm. It essentially matches any unspecified address.
-
-<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. 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). Note that subsequent <CODE>Port</CODE>
-statements for this vhost will not affect the ports assigned in the
-address set.
-
-<P>
-All vhosts are stored in a list which is in the reverse order that
-they appeared in the config file. For example, if the config file is:
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<BLOCKQUOTE><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 VirtualHost 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 VirtualHost
+ Matching</h1>
+
+ <p>This is a very rough document that was probably out of date
+ the moment it was written. It attempts to explain exactly what
+ the code does when deciding what virtual host to serve a hit
+ from. It's provided on the assumption that something is better
+ than nothing. The server version under discussion is Apache
+ 1.2.</p>
+
+ <p>If you just want to "make it work" without understanding
+ how, there's a <a href="#whatworks">What Works</a> section at
+ the bottom.</p>
+
+ <h3>Config File Parsing</h3>
+
+ <p>There is a main_server which consists of all the definitions
+ appearing outside of <code>VirtualHost</code> sections. There
+ are virtual servers, called <em>vhosts</em>, which are defined
+ by <a
+ href="../mod/core.html#virtualhost"><samp>VirtualHost</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>ServerName</code>, <code>ServerPath</code>, or
+ <code>ServerAlias</code>.</p>
+
+ <p>In the absence of any <a
+ href="../mod/core.html#listen"><samp>Listen</samp></a>
+ directives, the (final if there are multiple) <code>Port</code>
+ directive in the main_server indicates which port httpd will
+ listen on.</p>
+
+ <p>The <code>Port</code> and <code>ServerName</code> directives
+ for any server main or virtual are used when generating URLs
+ such as during redirects.</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>The magic <code>_default_</code> address has significance
+ during the matching algorithm. It essentially matches any
+ unspecified address.</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. 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). Note that subsequent
+ <code>Port</code> statements for this vhost will not affect the
+ ports assigned in the address set.</p>
+
+ <p>All vhosts are stored in a list which is in the reverse
+ order that they appeared in the config file. For example, if
+ the config file is:</p>
+
+ <blockquote>
+<pre>
<VirtualHost A>
...
</VirtualHost>
@@ -103,294 +102,285 @@
<VirtualHost C>
...
</VirtualHost>
-</PRE></BLOCKQUOTE>
-
-Then the list will be ordered: main_server, C, B, A. Keep this in mind.
+</pre>
+ </blockquote>
+ Then the list will be ordered: main_server, C, B, A. Keep this
+ in mind.
+
+ <p>After parsing has completed, the list of servers is scanned,
+ and various merges and 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>Now a pass is made through the vhosts to fill in any missing
+ <code>ServerName</code> fields and to classify the vhost as
+ either an <em>IP-based</em> vhost or a <em>name-based</em>
+ vhost. A vhost is considered a name-based vhost if any of its
+ address set overlaps the main_server (the port associated with
+ each address must match the main_server's <code>Port</code>).
+ Otherwise it is considered an IP-based vhost.</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. Any
+ vhost that includes the magic <samp>_default_</samp> wildcard
+ is given the same <code>ServerName</code> as the main_server.
+ Otherwise the vhost (which is necessarily an IP-based vhost) is
+ given a <code>ServerName</code> based on the result of a
+ reverse DNS lookup on the first address given in the
+ <code>VirtualHost</code> statement.</p>
+
+ <h3>Vhost Matching</h3>
+
+ <p><strong>Apache 1.3 differs from what is documented here, and
+ documentation still has to be written.</strong></p>
+
+ <p>The server determines which vhost to use for a request as
+ follows:</p>
+
+ <p><code>find_virtual_server</code>: When the connection is
+ first made by the client, the local IP address (the IP address
+ to which the client connected) is looked up in the server list.
+ A vhost is matched if it is an IP-based vhost, the IP address
+ matches and the port matches (taking into account
+ wildcards).</p>
+
+ <p>If no vhosts are matched then the last occurrence, if it
+ appears, of a <samp>_default_</samp> address (which if you
+ recall the ordering of the server list mentioned above means
+ that this would be the first occurrence of
+ <samp>_default_</samp> in the config file) is matched.</p>
+
+ <p>In any event, if nothing above has matched, then the
+ main_server is matched.</p>
+
+ <p>The vhost resulting from the above search is stored with
+ data about the connection. We'll call this the <em>connection
+ vhost</em>. The connection vhost is constant over all requests
+ in a particular TCP/IP session -- that is, over all requests in
+ a KeepAlive/persistent session.</p>
+
+ <p>For each request made on the connection the following
+ sequence of events further determines the actual vhost that
+ will be used to serve the request.</p>
+
+ <p><code>check_fulluri</code>: If the requestURI is an
+ absoluteURI, that is it includes <code>http://hostname/</code>,
+ then an attempt is made to determine if the hostname's address
+ (and optional port) match that of the connection vhost. If it
+ does then the hostname portion of the URI is saved as the
+ <em>request_hostname</em>. If it does not match, then the URI
+ remains untouched. <strong>Note</strong>: to achieve this
+ address comparison, the hostname supplied goes through a DNS
+ lookup unless it matches the <code>ServerName</code> or the
+ local IP address of the client's socket.</p>
+
+ <p><code>parse_uri</code>: If the URI begins with a protocol
+ (<em>i.e.</em>, <code>http:</code>, <code>ftp:</code>) then the
+ request is considered a proxy request. Note that even though we
+ may have stripped an <code>http://hostname/</code> in the
+ previous step, this could still be a proxy request.</p>
+
+ <p><code>read_request</code>: If the request does not have a
+ hostname from the earlier step, then any <code>Host:</code>
+ header sent by the client is used as the request hostname.</p>
+
+ <p><code>check_hostalias</code>: If the request now has a
+ hostname, then an attempt is made to match for this hostname.
+ The first step of this match is to compare any port, if one was
+ given in the request, against the <code>Port</code> field of
+ the connection vhost. If there's a mismatch then the vhost used
+ for the request is the connection vhost. (This is a bug, see
+ observations.)</p>
+
+ <p>If the port matches, then httpd scans the list of vhosts
+ starting with the next server <strong>after</strong> the
+ connection vhost. This scan does not stop if there are any
+ matches, it goes through all possible vhosts, and in the end
+ uses the last match it found. The comparisons performed are as
+ follows:</p>
+
+ <ul>
+ <li>Compare the request hostname:port with the vhost
+ <code>ServerName</code> and <code>Port</code>.</li>
+
+ <li>Compare the request hostname against any and all
+ addresses given in the <code>VirtualHost</code> directive for
+ this vhost.</li>
+
+ <li>Compare the request hostname against the
+ <code>ServerAlias</code> given for the vhost.</li>
+ </ul>
+
+ <p><code>check_serverpath</code>: If the request has no
+ hostname (back up a few paragraphs) then a scan similar to the
+ one in <code>check_hostalias</code> is performed to match any
+ <code>ServerPath</code> directives given in the vhosts. Note
+ that the <strong>last match</strong> is used regardless (again
+ consider the ordering of the virtual hosts).</p>
+
+ <h3>Observations</h3>
+
+ <ul>
+ <li>It is difficult to define an IP-based vhost for the
+ machine's "main IP address". You essentially have to create a
+ bogus <code>ServerName</code> for the main_server that does
+ not match the machine's IPs.</li>
+
+ <li>
+ During the scans in both <code>check_hostalias</code> and
+ <code>check_serverpath</code> no check is made that the
+ vhost being scanned is actually a name-based vhost. This
+ means, for example, that it's possible to match an IP-based
+ vhost through another address. But because the scan starts
+ in the vhost list at the first vhost that matched the local
+ IP address of the connection, not all IP-based vhosts can
+ be matched.
+
+ <p>Consider the config file above with three vhosts A, B,
+ C. Suppose that B is a named-based vhost, and A and C are
+ IP-based vhosts. If a request comes in on B or C's address
+ containing a header "<samp>Host: A</samp>" then it will be
+ served from A's config. If a request comes in on A's
+ address then it will always be served from A's config
+ regardless of any Host: header.</p>
+ </li>
+
+ <li>
+ Unless you have a <samp>_default_</samp> vhost, it doesn't
+ matter if you mix name-based vhosts in amongst IP-based
+ vhosts. During the <code>find_virtual_server</code> phase
+ above no named-based vhost will be matched, so the
+ main_server will remain the connection vhost. Then scans
+ will cover all vhosts in the vhost list.
+
+ <p>If you do have a <samp>_default_</samp> vhost, then you
+ cannot place named-based vhosts after it in the config.
+ This is because on any connection to the main server IPs
+ the connection vhost will always be the
+ <samp>_default_</samp> vhost since none of the name-based
+ are considered during <code>find_virtual_server</code>.</p>
+ </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. <a href="dns-caveats.html">There's more
+ information available on this and the next two
+ topics</a>.</li>
+
+ <li><code>ServerName</code> should always be set for each
+ vhost. Otherwise A DNS lookup is required for each
+ vhost.</li>
+
+ <li>A DNS lookup is always required for the main_server's
+ <code>ServerName</code> (or to generate that if it isn't
+ specified in the config).</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 Host header was available to disambiguate
+ the two.)</li>
+
+ <li>If a vhost that would otherwise be a name-vhost includes
+ a <code>Port</code> statement that doesn't match the
+ main_server <code>Port</code> then it will be considered an
+ IP-based vhost. Then <code>find_virtual_server</code> will
+ match it (because the ports associated with each address in
+ the address set default to the port of the main_server) as
+ the connection vhost. Then <code>check_hostalias</code> will
+ refuse to check any other name-based vhost because of the
+ port mismatch. The result is that the vhost will steal all
+ hits going to the main_server address.</li>
+
+ <li>If two IP-based vhosts have an address in common, the
+ vhost appearing later in the file is always matched. Such a
+ thing might happen inadvertently. If the config has
+ name-based vhosts and for some reason the main_server
+ <code>ServerName</code> resolves to the wrong address then
+ all the name-based vhosts will be parsed as ip-based vhosts.
+ Then the last of them will steal all the hits.</li>
+
+ <li>The last name-based vhost in the config is always matched
+ for any hit which doesn't match one of the other name-based
+ vhosts.</li>
+ </ul>
+
+ <h3><a id="whatworks" name="whatworks">What Works</a></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 VirtualHost
+ definitions. (This is to aid the readability of the
+ configuration -- the post-config merging process makes it
+ non-obvious that definitions mixed in around virtualhosts
+ might affect all virtualhosts.)</li>
+
+ <li>Arrange your VirtualHosts such that all name-based
+ virtual hosts come first, followed by IP-based virtual hosts,
+ followed by any <samp>_default_</samp> virtual host</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 /abcdef").</li>
+
+ <li>Do not use <em>port-based</em> vhosts in the same server
+ as name-based vhosts. A loose definition for port-based is a
+ vhost which is determined by the port on the server
+ (<em>i.e.</em>, one server with ports 8000, 8080, and 80 -
+ all of which have different configurations).</li>
+ </ul>
+ <!--#include virtual="footer.html" -->
+ </body>
+</html>
-<P>
-After parsing has completed, the list of servers is scanned, and various
-merges and 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 "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>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 "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> Now a pass is made through the vhosts to fill in any missing
-<CODE>ServerName</CODE> fields and to classify the vhost as either
-an <EM>IP-based</EM> vhost or a <EM>name-based</EM> vhost. A vhost is
-considered a name-based vhost if any of its address set overlaps the
-main_server (the port associated with each address must match the
-main_server's <CODE>Port</CODE>). Otherwise it is considered an IP-based
-vhost.
-
-<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. Any vhost that includes the magic
-<SAMP>_default_</SAMP> wildcard is given the same <CODE>ServerName</CODE> as
-the main_server. Otherwise the vhost (which is necessarily an IP-based
-vhost) is given a <CODE>ServerName</CODE> based on the result of a reverse
-DNS lookup on the first address given in the <CODE>VirtualHost</CODE>
-statement.
-
-<P>
-
-<H3>Vhost Matching</H3>
-
-
-<P><STRONG>Apache 1.3 differs from what is documented
-here, and documentation still has to be written.</STRONG>
-
-<P>
-The server determines which vhost to use for a request as follows:
-
-<P> <CODE>find_virtual_server</CODE>: When the connection is first made
-by the client, the local IP address (the IP address to which the client
-connected) is looked up in the server list. A vhost is matched if it
-is an IP-based vhost, the IP address matches and the port matches
-(taking into account wildcards).
-
-<P> If no vhosts are matched then the last occurrence, if it appears,
-of a <SAMP>_default_</SAMP> address (which if you recall the ordering of the
-server list mentioned above means that this would be the first occurrence
-of <SAMP>_default_</SAMP> in the config file) is matched.
-
-<P> In any event, if nothing above has matched, then the main_server is
-matched.
-
-<P> The vhost resulting from the above search is stored with data
-about the connection. We'll call this the <EM>connection vhost</EM>.
-The connection vhost is constant over all requests in a particular TCP/IP
-session -- that is, over all requests in a KeepAlive/persistent session.
-
-<P> For each request made on the connection the following sequence of
-events further determines the actual vhost that will be used to serve
-the request.
-
-<P> <CODE>check_fulluri</CODE>: If the requestURI is an absoluteURI, that
-is it includes <CODE>http://hostname/</CODE>, then an attempt is made to
-determine if the hostname's address (and optional port) match that of
-the connection vhost. If it does then the hostname portion of the URI
-is saved as the <EM>request_hostname</EM>. If it does not match, then the
-URI remains untouched. <STRONG>Note</STRONG>: to achieve this address
-comparison,
-the hostname supplied goes through a DNS lookup unless it matches the
-<CODE>ServerName</CODE> or the local IP address of the client's socket.
-
-<P> <CODE>parse_uri</CODE>: If the URI begins with a protocol
-(<EM>i.e.</EM>, <CODE>http:</CODE>, <CODE>ftp:</CODE>) then the request is
-considered a proxy request. Note that even though we may have stripped
-an <CODE>http://hostname/</CODE> in the previous step, this could still
-be a proxy request.
-
-<P> <CODE>read_request</CODE>: If the request does not have a hostname
-from the earlier step, then any <CODE>Host:</CODE> header sent by the
-client is used as the request hostname.
-
-<P> <CODE>check_hostalias</CODE>: If the request now has a hostname,
-then an attempt is made to match for this hostname. The first step
-of this match is to compare any port, if one was given in the request,
-against the <CODE>Port</CODE> field of the connection vhost. If there's
-a mismatch then the vhost used for the request is the connection vhost.
-(This is a bug, see observations.)
-
-<P>
-If the port matches, then httpd scans the list of vhosts starting with
-the next server <STRONG>after</STRONG> the connection vhost. This scan does not
-stop if there are any matches, it goes through all possible vhosts,
-and in the end uses the last match it found. The comparisons performed
-are as follows:
-
-<UL>
-<LI>Compare the request hostname:port with the vhost
- <CODE>ServerName</CODE> and <CODE>Port</CODE>.
-
-<LI>Compare the request hostname against any and all addresses given in
- the <CODE>VirtualHost</CODE> directive for this vhost.
-
-<LI>Compare the request hostname against the <CODE>ServerAlias</CODE>
- given for the vhost.
-</UL>
-
-<P>
-<CODE>check_serverpath</CODE>: If the request has no hostname
-(back up a few paragraphs) then a scan similar to the one
-in <CODE>check_hostalias</CODE> is performed to match any
-<CODE>ServerPath</CODE> directives given in the vhosts. Note that the
-<STRONG>last match</STRONG> is used regardless (again consider the ordering of
-the virtual hosts).
-
-<H3>Observations</H3>
-
-<UL>
-
-<LI>It is difficult to define an IP-based vhost for the machine's
- "main IP address". You essentially have to create a bogus
- <CODE>ServerName</CODE> for the main_server that does not match the
- machine's IPs.
- <P>
-
-<LI>During the scans in both <CODE>check_hostalias</CODE> and
- <CODE>check_serverpath</CODE> no check is made that the vhost being
- scanned is actually a name-based vhost. This means, for example, that
- it's possible to match an IP-based vhost through another address. But
- because the scan starts in the vhost list at the first vhost that
- matched the local IP address of the connection, not all IP-based vhosts
- can be matched.
- <P>
- Consider the config file above with three vhosts A, B, C. Suppose
- that B is a named-based vhost, and A and C are IP-based vhosts. If
- a request comes in on B or C's address containing a header
- "<SAMP>Host: A</SAMP>" then
- it will be served from A's config. If a request comes in on A's
- address then it will always be served from A's config regardless of
- any Host: header.
- </P>
-
-<LI>Unless you have a <SAMP>_default_</SAMP> vhost,
- it doesn't matter if you mix name-based vhosts in amongst IP-based
- vhosts. During the <CODE>find_virtual_server</CODE> phase above no
- named-based vhost will be matched, so the main_server will remain the
- connection vhost. Then scans will cover all vhosts in the vhost list.
- <P>
- If you do have a <SAMP>_default_</SAMP> vhost, then you cannot place
- named-based vhosts after it in the config. This is because on any
- connection to the main server IPs the connection vhost will always be
- the <SAMP>_default_</SAMP> vhost since none of the name-based are
- considered during <CODE>find_virtual_server</CODE>.
- </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.
- <A HREF="dns-caveats.html">There's more information
- available on this and the next two topics</A>.
- <P>
-
-<LI><CODE>ServerName</CODE> should always be set for each vhost. Otherwise
- A DNS lookup is required for each vhost.
- <P>
-
-<LI>A DNS lookup is always required for the main_server's
- <CODE>ServerName</CODE> (or to generate that if it isn't specified
- in the config).
- <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
- Host header was available to disambiguate the two.)
- <P>
-
-<LI>If a vhost that would otherwise be a name-vhost includes a
- <CODE>Port</CODE> statement that doesn't match the main_server
- <CODE>Port</CODE> then it will be considered an IP-based vhost.
- Then <CODE>find_virtual_server</CODE> will match it (because
- the ports associated with each address in the address set default
- to the port of the main_server) as the connection vhost. Then
- <CODE>check_hostalias</CODE> will refuse to check any other name-based
- vhost because of the port mismatch. The result is that the vhost
- will steal all hits going to the main_server address.
- <P>
-
-<LI>If two IP-based vhosts have an address in common, the vhost appearing
- later in the file is always matched. Such a thing might happen
- inadvertently. If the config has name-based vhosts and for some reason
- the main_server <CODE>ServerName</CODE> resolves to the wrong address
- then all the name-based vhosts will be parsed as ip-based vhosts.
- Then the last of them will steal all the hits.
- <P>
-
-<LI>The last name-based vhost in the config is always matched for any hit
- which doesn't match one of the other name-based vhosts.
-
-</UL>
-
-<H3><A NAME="whatworks">What Works</A></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 VirtualHost definitions.
-(This is to aid the readability of the configuration -- the post-config
-merging process makes it non-obvious that definitions mixed in around
-virtualhosts might affect all virtualhosts.)
-<P>
-
-<LI>Arrange your VirtualHosts such
-that all name-based virtual hosts come first, followed by IP-based
-virtual hosts, followed by any <SAMP>_default_</SAMP> virtual host
-<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>, "ServerPath /abc" should appear after
-"ServerPath /abcdef").
-<P>
-
-<LI>Do not use <EM>port-based</EM> vhosts in the same server as
-name-based vhosts. A loose definition for port-based is a vhost which
-is determined by the port on the server (<EM>i.e.</EM>, one server with
-ports 8000, 8080, and 80 - all of which have different configurations).
-<P>
-
-</UL>
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
1.10 +232 -201 httpd-docs-1.3/htdocs/manual/vhosts/virtual-host.html
Index: virtual-host.html
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/htdocs/manual/vhosts/virtual-host.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- virtual-host.html 2000/11/22 04:31:41 1.9
+++ virtual-host.html 2001/10/08 01:37:37 1.10
@@ -1,195 +1,225 @@
-<!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">Virtual Host Support</H1>
-
-<STRONG>See Also:</STRONG>
-<A HREF="host.html">Non-IP based virtual hosts</A>
-
-<H2>What are virtual hosts?</H2>
-This is the ability of a single machine to be a web server for multiple
-domains. For example, an Internet service provider might have a machine
-called <CODE>www.serve.com</CODE> which provides Web space for several
-organizations including, say, <EM>smallco</EM> and <EM>baygroup</EM>.
-Ordinarily, these groups would be given parts of the Web tree on www.serve.com.
-So smallco's home page would have the URL
-<BLOCKQUOTE>
-http://www.serve.com/smallco/
-</BLOCKQUOTE>
-and baygroup's home page would have the URL
-<BLOCKQUOTE>
-http://www.serve.com/baygroup/
-</BLOCKQUOTE>
-<P>
-For esthetic reasons, however, both organizations would rather their home
-pages appeared under their own names rather than that of the service
-provider's; but they do not want to set up their own Internet links and
-servers.
-<P>
-Virtual hosts are the solution to this problem. smallco and baygroup would
-have their own Internet name registrations, <CODE>www.smallco.com</CODE> and
-<CODE>www.baygroup.org</CODE> respectively. These hostnames would both
-correspond to the service provider's machine (www.serve.com). Thus
-smallco's home page would now have the URL
-<BLOCKQUOTE>
-http://www.smallco.com/
-</BLOCKQUOTE>
-and baygroup's home page would would have the URL
-<BLOCKQUOTE>
-http://www.baygroup.org/
-</BLOCKQUOTE>
-
-<H2>System requirements</H2>
-Due to limitations in the HTTP/1.0 protocol, the web server <STRONG>must have a
-different IP address for each virtual host</STRONG>. This can be achieved
-by the machine having several physical network connections, or by use
-of a <A HREF="../misc/vif-info.html">virtual interface</A> on some operating
-systems.
-
-<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>The different virtual hosts need very different httpd configurations, such
- as different values for:
- <A HREF="../mod/core.html#servertype">ServerType</A>,
- <A HREF="../mod/core.html#user">User</A>,
- <A HREF="../mod/core.html#group">Group</A>,
- <A HREF="../mod/mod_mime.html#typesconfig">TypesConfig</A> or
- <A HREF="../mod/core.html#serverroot">ServerRoot</A>.
-<LI>The machine does not process a very high request rate.
-</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#bindaddress">BindAddress</A> directive in the
-configuration
-file to select which IP address (or virtual host) that daemon services.
-<EM>E.g.</EM>,
-<BLOCKQUOTE><CODE>BindAddress www.smallco.com</CODE></BLOCKQUOTE>
-This hostname can also be given as an IP address.
-
-<H2>Setting up a single daemon</H2>
-For this case, a single httpd will service requests for 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> configuration
-directives to different values for each virtual host.
-<EM>E.g.</EM>,
-<BLOCKQUOTE><CODE>
-<VirtualHost www.smallco.com><BR>
-ServerAdmin webmaster@mail.smallco.com<BR>
-DocumentRoot /groups/smallco/www<BR>
-ServerName www.smallco.com<BR>
-ErrorLog /groups/smallco/logs/error_log<BR>
-TransferLog /groups/smallco/logs/access_log<BR>
-</VirtualHost><BR>
-<BR>
-<VirtualHost www.baygroup.org><BR>
-ServerAdmin webmaster@mail.baygroup.org<BR>
-DocumentRoot /groups/baygroup/www<BR>
-ServerName www.baygroup.org<BR>
-ErrorLog /groups/baygroup/logs/error_log<BR>
-TransferLog /groups/baygroup/logs/access_log<BR>
-</VirtualHost><BR>
-</CODE></BLOCKQUOTE>
-
-This VirtualHost hostnames can also be given as IP addresses.
-
-<P>
-
-Almost <STRONG>ANY</STRONG> configuration directive can be put
-in the VirtualHost directive, with the exception of
-<A HREF="../mod/core.html#servertype">ServerType</A>,
-<A HREF="../mod/core.html#user">User</A>,
-<A HREF="../mod/core.html#group">Group</A>,
-<A HREF="../mod/core.html#startservers">StartServers</A>,
-<A HREF="../mod/core.html#maxspareservers">MaxSpareServers</A>,
-<A HREF="../mod/core.html#minspareservers">MinSpareServers</A>,
-<A HREF="../mod/core.html#maxrequestsperchild">MaxRequestsPerChild</A>,
-<A HREF="../mod/core.html#bindaddress">BindAddress</A>,
-<A HREF="../mod/core.html#pidfile">PidFile</A>,
-<A HREF="../mod/mod_mime.html#typesconfig">TypesConfig</A>, and
-<A HREF="../mod/core.html#serverroot">ServerRoot</A>.
-
-<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>
-
-<H2>File Handle/Resource Limits:</H2>
-When using a large number of Virtual Hosts, Apache may run out of available
-file descriptors 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>
-
-The have been reports that Apache may start running out of resources allocated
-for the root process. This will exhibit itself as errors in the error log like
-"unable to fork". There are two ways you can bump this up:
-
-<OL>
-<LI>Have a <CODE>csh</CODE> script wrapper around httpd which sets the
-"rlimit" to some large number, like 512.
-<LI>Edit http_main.c to add calls to setrlimit() from main(), along the lines
-of
-<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 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">Virtual Host Support</h1>
+ <strong>See Also:</strong> <a href="host.html">Non-IP based
+ virtual hosts</a>
+
+ <h2>What are virtual hosts?</h2>
+ This is the ability of a single machine to be a web server for
+ multiple domains. For example, an Internet service provider
+ might have a machine called <code>www.serve.com</code> which
+ provides Web space for several organizations including, say,
+ <em>smallco</em> and <em>baygroup</em>. Ordinarily, these
+ groups would be given parts of the Web tree on www.serve.com.
+ So smallco's home page would have the URL
+
+ <blockquote>
+ http://www.serve.com/smallco/
+ </blockquote>
+ and baygroup's home page would have the URL
+
+ <blockquote>
+ http://www.serve.com/baygroup/
+ </blockquote>
+
+ <p>For esthetic reasons, however, both organizations would
+ rather their home pages appeared under their own names rather
+ than that of the service provider's; but they do not want to
+ set up their own Internet links and servers.</p>
+
+ <p>Virtual hosts are the solution to this problem. smallco and
+ baygroup would have their own Internet name registrations,
+ <code>www.smallco.com</code> and <code>www.baygroup.org</code>
+ respectively. These hostnames would both correspond to the
+ service provider's machine (www.serve.com). Thus smallco's home
+ page would now have the URL</p>
+
+ <blockquote>
+ http://www.smallco.com/
+ </blockquote>
+ and baygroup's home page would would have the URL
+
+ <blockquote>
+ http://www.baygroup.org/
+ </blockquote>
+
+ <h2>System requirements</h2>
+ Due to limitations in the HTTP/1.0 protocol, the web server
+ <strong>must have a different IP address for each virtual
+ host</strong>. This can be achieved by the machine having
+ several physical network connections, or by use of a <a
+ href="../misc/vif-info.html">virtual interface</a> on some
+ operating systems.
+
+ <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>The different virtual hosts need very different httpd
+ configurations, such as different values for: <a
+ href="../mod/core.html#servertype">ServerType</a>, <a
+ href="../mod/core.html#user">User</a>, <a
+ href="../mod/core.html#group">Group</a>, <a
+ href="../mod/mod_mime.html#typesconfig">TypesConfig</a> or <a
+ href="../mod/core.html#serverroot">ServerRoot</a>.</li>
+
+ <li>The machine does not process a very high request
+ rate.</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#bindaddress">BindAddress</a> directive
+ in the configuration file to select which IP address (or
+ virtual host) that daemon services. <em>E.g.</em>,
+
+ <blockquote>
+ <code>BindAddress www.smallco.com</code>
+ </blockquote>
+ This hostname can also be given as an IP address.
+
+ <h2>Setting up a single daemon</h2>
+ For this case, a single httpd will service requests for 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>
+ configuration directives to different values for each virtual
+ host. <em>E.g.</em>,
+
+ <blockquote>
+ <code><VirtualHost www.smallco.com><br />
+ ServerAdmin webmaster@mail.smallco.com<br />
+ DocumentRoot /groups/smallco/www<br />
+ ServerName www.smallco.com<br />
+ ErrorLog /groups/smallco/logs/error_log<br />
+ TransferLog /groups/smallco/logs/access_log<br />
+ </VirtualHost><br />
+ <br />
+ <VirtualHost www.baygroup.org><br />
+ ServerAdmin webmaster@mail.baygroup.org<br />
+ DocumentRoot /groups/baygroup/www<br />
+ ServerName www.baygroup.org<br />
+ ErrorLog /groups/baygroup/logs/error_log<br />
+ TransferLog /groups/baygroup/logs/access_log<br />
+ </VirtualHost><br />
+ </code>
+ </blockquote>
+ This VirtualHost hostnames can also be given as IP addresses.
+
+ <p>Almost <strong>ANY</strong> configuration directive can be
+ put in the VirtualHost directive, with the exception of <a
+ href="../mod/core.html#servertype">ServerType</a>, <a
+ href="../mod/core.html#user">User</a>, <a
+ href="../mod/core.html#group">Group</a>, <a
+ href="../mod/core.html#startservers">StartServers</a>, <a
+ href="../mod/core.html#maxspareservers">MaxSpareServers</a>, <a
+ href="../mod/core.html#minspareservers">MinSpareServers</a>, <a
+ href="../mod/core.html#maxrequestsperchild">MaxRequestsPerChild</a>,
+ <a href="../mod/core.html#bindaddress">BindAddress</a>, <a
+ href="../mod/core.html#pidfile">PidFile</a>, <a
+ href="../mod/mod_mime.html#typesconfig">TypesConfig</a>, and <a
+ href="../mod/core.html#serverroot">ServerRoot</a>.</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>
+
+ <h2>File Handle/Resource Limits:</h2>
+ When using a large number of Virtual Hosts, Apache may run out
+ of available file descriptors 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:</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>
+ The have been reports that Apache may start running out of
+ resources allocated for the root process. This will exhibit
+ itself as errors in the error log like "unable to fork". There
+ are two ways you can bump this up:
+
+ <ol>
+ <li>Have a <code>csh</code> script wrapper around httpd which
+ sets the "rlimit" to some large number, like 512.</li>
+
+ <li>
+ Edit http_main.c to add calls to setrlimit() from main(),
+ along the lines of
+<pre>
struct rlimit rlp;
rlp.rlim_cur = rlp.rlim_max = 512;
@@ -197,12 +227,13 @@
fprintf(stderr, "setrlimit(RLIMIT_NPROC) failed.\n");
exit(1);
}
-</PRE>
-(thanks to "Aaron Gifford <agifford@InfoWest.COM>" for the patch)
-</OL>
-
-The latter will probably manifest itself in a later version of Apache.
-
-<!--#include virtual="footer.html" -->
-</BODY>
-</HTML>
+</pre>
+ (thanks to "Aaron Gifford <agifford@InfoWest.COM>"
+ for the patch)
+ </li>
+ </ol>
+ The latter will probably manifest itself in a later version of
+ Apache. <!--#include virtual="footer.html" -->
+ </body>
+</html>
+