diff options
Diffstat (limited to 'docs/manual/vhosts')
| -rw-r--r-- | docs/manual/vhosts/details.html | 373 | ||||
| -rw-r--r-- | docs/manual/vhosts/details_1_2.html | 396 | ||||
| -rw-r--r-- | docs/manual/vhosts/examples.html | 512 | ||||
| -rw-r--r-- | docs/manual/vhosts/fd-limits.html | 59 | ||||
| -rw-r--r-- | docs/manual/vhosts/fd-limits.html.en | 59 | ||||
| -rw-r--r-- | docs/manual/vhosts/footer.html | 8 | ||||
| -rw-r--r-- | docs/manual/vhosts/header.html | 6 | ||||
| -rw-r--r-- | docs/manual/vhosts/host.html | 172 | ||||
| -rw-r--r-- | docs/manual/vhosts/index.html | 65 | ||||
| -rw-r--r-- | docs/manual/vhosts/index.html.en | 65 | ||||
| -rw-r--r-- | docs/manual/vhosts/ip-based.html | 140 | ||||
| -rw-r--r-- | docs/manual/vhosts/mass.html | 330 | ||||
| -rw-r--r-- | docs/manual/vhosts/name-based.html | 164 | ||||
| -rw-r--r-- | docs/manual/vhosts/name-based.html.en | 164 | ||||
| -rw-r--r-- | docs/manual/vhosts/vhosts-in-depth.html | 396 | ||||
| -rw-r--r-- | docs/manual/vhosts/virtual-host.html | 208 |
16 files changed, 0 insertions, 3117 deletions
diff --git a/docs/manual/vhosts/details.html b/docs/manual/vhosts/details.html deleted file mode 100644 index f14bd088a5..0000000000 --- a/docs/manual/vhosts/details.html +++ /dev/null @@ -1,373 +0,0 @@ -<!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. - -<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): - -<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 - <VirtualHost 111.22.33.44> | ... - # 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> - <VirtualHost 111.22.33.55> | - # server D | NameVirtualHost 111.22.33.44 - ... | NameVirtualHost 111.22.33.55 - </VirtualHost> | - | -</PRE> - -<P>(To aid the readability of your configuration you should prefer the -left variant.) - -<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>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. - <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> diff --git a/docs/manual/vhosts/details_1_2.html b/docs/manual/vhosts/details_1_2.html deleted file mode 100644 index 23d8e919a1..0000000000 --- a/docs/manual/vhosts/details_1_2.html +++ /dev/null @@ -1,396 +0,0 @@ -<!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: - -<BLOCKQUOTE><PRE> - <VirtualHost A> - ... - </VirtualHost> - - <VirtualHost B> - ... - </VirtualHost> - - <VirtualHost C> - ... - </VirtualHost> -</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: - -<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> diff --git a/docs/manual/vhosts/examples.html b/docs/manual/vhosts/examples.html deleted file mode 100644 index 46697bcec4..0000000000 --- a/docs/manual/vhosts/examples.html +++ /dev/null @@ -1,512 +0,0 @@ -<!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="#ip">IP-based vhosts only</A> -<LI><A HREF="#name">Name-based vhosts only</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="ip">IP-based vhosts only</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> - - - <BLOCKQUOTE><PRE> - ... - Port 80 - DocumentRoot /www/domain - ServerName www.domain.tld - - <VirtualHost 111.22.33.55> - DocumentRoot /www/otherdomain - 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> - - <BLOCKQUOTE><PRE> - ... - Port 80 - ServerName server.domain.tld - - <VirtualHost 111.22.33.44> - DocumentRoot /www/domain - ServerName www.domain.tld - ... - </VirtualHost> - - <VirtualHost 111.22.33.55> - DocumentRoot /www/otherdomain - 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> - - <BLOCKQUOTE><PRE> - ... - Port 80 - Listen 111.22.33.44:80 - Listen 111.22.33.55:8080 - ServerName server.domain.tld - - <VirtualHost 111.22.33.44:80> - DocumentRoot /www/domain - ServerName www.domain.tld - ... - </VirtualHost> - - <VirtualHost 111.22.33.55:8080> - ServerName www-cache.domain.tld - ... - <Directory proxy:> - order deny,allow - deny from all - 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="name">Name-based vhosts only</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> - - <BLOCKQUOTE><PRE> - ... - Port 80 - ServerName server.domain.tld - - NameVirtualHost 111.22.33.44 - - <VirtualHost 111.22.33.44> - DocumentRoot /www/domain - ServerName www.domain.tld - ... - </VirtualHost> - - <VirtualHost 111.22.33.44> - DocumentRoot /www/subdomain - 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 one virtual host should - catch any request to hostnames of the form - <SAMP>*.sub.domain.tld</SAMP> with <SAMP>www.sub.domain.tld</SAMP> - as its server name. The address <SAMP>111.22.33.55</SAMP> should be - used for the virtual hosts. - <P> - <STRONG>Server configuration:</STRONG> - - <BLOCKQUOTE><PRE> - ... - Port 80 - ServerName www.domain.tld - DocumentRoot /www/domain - - NameVirtualHost 111.22.33.55 - - <VirtualHost 111.22.33.55> - DocumentRoot /www/otherdomain - ServerName www.otherdomain.tld - ... - </VirtualHost> - - <VirtualHost 111.22.33.55> - DocumentRoot /www/subdomain - ServerName www.sub.domain.tld - 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> -</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> - - <BLOCKQUOTE><PRE> - ... - Port 80 - ServerName server.domain.tld - - NameVirtualHost 111.22.33.44 - - <VirtualHost 111.22.33.44> - DocumentRoot /www/domain - ServerName www.domain.tld - ... - </VirtualHost> - - <VirtualHost 111.22.33.44> - DocumentRoot /www/subdomain1 - ServerName www.sub1.domain.tld - ... - </VirtualHost> - - <VirtualHost 111.22.33.44> - DocumentRoot /www/subdomain2 - ServerName www.sub2.domain.tld - ... - </VirtualHost> - - <VirtualHost 111.22.33.55> - DocumentRoot /www/otherdomain1 - ServerName www.otherdomain1.tld - ... - </VirtualHost> - - <VirtualHost 111.22.33.66> - DocumentRoot /www/otherdomain2 - ServerName www.otherdomain2.tld - ... - </VirtualHost> - </PRE></BLOCKQUOTE> - -</UL> - -<HR> - -<H3><A 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. - <P> - <STRONG>Server configuration:</STRONG> - - <BLOCKQUOTE><PRE> - ... - Listen 80 - Listen 8080 - ServerName www.domain.tld - DocumentRoot /www/domain - - <VirtualHost 111.22.33.44:8080> - 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> - - <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> - - <BLOCKQUOTE><PRE> - ... - <VirtualHost _default_:80> - DocumentRoot /www/default80 - ... - </VirtualHost> - - <VirtualHost _default_:*> - 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> - - <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> - - <BLOCKQUOTE><PRE> - ... - Port 80 - ServerName www.domain.tld - DocumentRoot /www/domain - - NameVirtualHost 111.22.33.55 - - <VirtualHost 111.22.33.55 111.22.33.66> - DocumentRoot /www/otherdomain - ServerName www.otherdomain.tld - ... - </VirtualHost> - - <VirtualHost 111.22.33.55> - DocumentRoot /www/subdomain - ServerName www.sub.domain.tld - 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> - - <BLOCKQUOTE><PRE> - ... - NameVirtualHost 111.22.33.44 - - <VirtualHost 111.22.33.44> - # primary vhost - DocumentRoot /www/subdomain - RewriteEngine On - RewriteRule ^/.* /www/subdomain/index.html - ... - </VirtualHost> - - <VirtualHost 111.22.33.44> - DocumentRoot /www/subdomain/sub1 - ServerName www.sub1.domain.tld - ServerPath /sub1/ - RewriteEngine On - RewriteRule ^(/sub1/.*) /www/subdomain$1 - ... - </VirtualHost> - - <VirtualHost 111.22.33.44> - DocumentRoot /www/subdomain/sub2 - ServerName www.sub2.domain.tld - ServerPath /sub2/ - RewriteEngine On - 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> diff --git a/docs/manual/vhosts/fd-limits.html b/docs/manual/vhosts/fd-limits.html deleted file mode 100644 index 6b9d0f93c4..0000000000 --- a/docs/manual/vhosts/fd-limits.html +++ /dev/null @@ -1,59 +0,0 @@ -<!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> - -<!--#include virtual="footer.html" --> -</BODY></HTML> - diff --git a/docs/manual/vhosts/fd-limits.html.en b/docs/manual/vhosts/fd-limits.html.en deleted file mode 100644 index 6b9d0f93c4..0000000000 --- a/docs/manual/vhosts/fd-limits.html.en +++ /dev/null @@ -1,59 +0,0 @@ -<!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> - -<!--#include virtual="footer.html" --> -</BODY></HTML> - diff --git a/docs/manual/vhosts/footer.html b/docs/manual/vhosts/footer.html deleted file mode 100644 index 7fe745dcfd..0000000000 --- a/docs/manual/vhosts/footer.html +++ /dev/null @@ -1,8 +0,0 @@ -<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> diff --git a/docs/manual/vhosts/header.html b/docs/manual/vhosts/header.html deleted file mode 100644 index 5662300029..0000000000 --- a/docs/manual/vhosts/header.html +++ /dev/null @@ -1,6 +0,0 @@ -<DIV ALIGN="CENTER"> - <IMG SRC="../images/sub.gif" ALT="[APACHE DOCUMENTATION]"> - <H3> - Apache HTTP Server Version 1.3 - </H3> -</DIV> diff --git a/docs/manual/vhosts/host.html b/docs/manual/vhosts/host.html deleted file mode 100644 index 5788676af8..0000000000 --- a/docs/manual/vhosts/host.html +++ /dev/null @@ -1,172 +0,0 @@ -<!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> - <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> - ServerAlias apache.org *.apache.org -</PRE> - -<P>Note that you can use <CODE>*</CODE> and <CODE>?</CODE> as wild-card -characters.</P> - -<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: - -<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> diff --git a/docs/manual/vhosts/index.html b/docs/manual/vhosts/index.html deleted file mode 100644 index 9a569028cf..0000000000 --- a/docs/manual/vhosts/index.html +++ /dev/null @@ -1,65 +0,0 @@ -<!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="ip-based.html">IP-based Virtual Hosts</A> -<LI><A HREF="name-based.html">Name-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 with mod_rewrite</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> diff --git a/docs/manual/vhosts/index.html.en b/docs/manual/vhosts/index.html.en deleted file mode 100644 index 9a569028cf..0000000000 --- a/docs/manual/vhosts/index.html.en +++ /dev/null @@ -1,65 +0,0 @@ -<!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="ip-based.html">IP-based Virtual Hosts</A> -<LI><A HREF="name-based.html">Name-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 with mod_rewrite</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> diff --git a/docs/manual/vhosts/ip-based.html b/docs/manual/vhosts/ip-based.html deleted file mode 100644 index 14e529da75..0000000000 --- a/docs/manual/vhosts/ip-based.html +++ /dev/null @@ -1,140 +0,0 @@ -<!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> - 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> - <VirtualHost www.smallco.com> - ServerAdmin webmaster@mail.smallco.com - DocumentRoot /groups/smallco/www - ServerName www.smallco.com - ErrorLog /groups/smallco/logs/error_log - TransferLog /groups/smallco/logs/access_log - </VirtualHost> - - <VirtualHost www.baygroup.org> - ServerAdmin webmaster@mail.baygroup.org - DocumentRoot /groups/baygroup/www - ServerName www.baygroup.org - 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 -<A HREF="../mod/core.html#servertype">ServerType</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#listen">Listen</A>, -<A HREF="../mod/core.html#pidfile">PidFile</A>, -<A HREF="../mod/mod_mime.html#typesconfig">TypesConfig</A>, -<A HREF="../mod/core.html#serverroot">ServerRoot</A> and -<A HREF="../mod/core.html#namevirtualhost">NameVirtualHost</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> - diff --git a/docs/manual/vhosts/mass.html b/docs/manual/vhosts/mass.html deleted file mode 100644 index 10b763f85a..0000000000 --- a/docs/manual/vhosts/mass.html +++ /dev/null @@ -1,330 +0,0 @@ -<!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. Some familiarity with -<A HREF="../mod/mod_rewrite.html"><CODE>mod_rewrite</CODE></A> is -useful.</P> - -<!-- - -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 of the technique</A> -<LI><A HREF="#simple">Simple name-based dynamic virtual hosts</A> -<LI><A HREF="#homepages">A virtually hosted homepages system</A> -<LI><A HREF="#xtra-conf">Using a separate virtual host configuration file</A> -<LI><A HREF="#combinations">Using more than one virtual hosting system on the same server</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 hundreds of -<CODE><VirtualHost></CODE> sections that are substantially the -same, for example: -<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 -</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 -</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 -</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 server; however if you have very many virtual hosts then -doing this is dubious anyway because it eats file descriptors. It's -better to log to a pipe or a fifo and arrange for the process at the -other end to distribute the logs (and perhaps accumulate statistics, -etc.). A <CODE>LogFormat</CODE> directive that includes -<CODE>%{SERVER_NAME}e</CODE> for the virtual host makes it easy to do this.</P> - - -<HR><H2><A NAME="overview">Overview of the technique</A></H2> - -<P>All of the dynamic virtual hosts will either be configured as part -of the main server configuration, or within a -<CODE><VirtualHost></CODE> section. For a simple (very uniform) -setup, <CODE><VirtualHost></CODE> sections aren't needed at all.</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 -(configured with <CODE>ServerName</CODE> and available to CGIs via the -<CODE>SERVER_NAME</CODE> environment variable). The way it is -determined is controlled by the <CODE>UseCanonicalName</CODE> -directive: with <CODE>UseCanonicalName off</CODE> the server name -comes from the contents of the <CODE>Host:</CODE> header in the -request. If there is no <CODE>Host:</CODE> header then the value -configured with <CODE>ServerName</CODE> is used instead.</P> - -<P>The other one is the document root (configured with -<CODE>DocumentRoot</CODE> and available to CGIs via the -<CODE>DOCUMENT_ROOT</CODE> environment variable). This is used by the -core module when mapping URIs to filenames, but in the context of -dynamic virtual hosting its value only matters if any CGIs or SSI -documents make use of the <CODE>DOCUMENT_ROOT</CODE> environment -variable. This is an Apache extension to the CGI specification and as -such shouldn't really be relied upon, especially because this -technique breaks it: there isn't currently a way of setting -<CODE>DOCUMENT_ROOT</CODE> dynamically.</P> - -<P>The meat of the mechanism works via Apache's URI-to-filename -translation API phase. This is used by a number of modules: -<A HREF="../mod/mod_rewrite.html"><CODE>mod_rewrite</CODE></A>, -<A HREF="../mod/mod_alias.html"><CODE>mod_alias</CODE></A>, -<A HREF="../mod/mod_userdir.html"><CODE>mod_userdir</CODE></A>, -and <A HREF="../mod/core.html">the core module</A>. -In the default configuration these modules are called in that order -and given a chance to say that they know what the filename is. Most of -these modules do it in a fairly simple fashion (e.g. the core module -concatenates the document root and the URI) except for -<CODE>mod_rewrite</CODE>, which provides enough functionality to do -all sorts of sick and twisted things (like dynamic virtual hosting). -Note that because of the order in which the modules are called, using -a <CODE>mod_rewrite</CODE> configuration that matches any URI means -that the other modules (particularly <CODE>mod_alias</CODE>) will -cease to function. The examples below show how to deal with this.</P> - -<P><STRONG>The dynamic virtual hosting idea is very simple: use the -server name as well as the URI to determine the corresponding -filename.</STRONG></P> - - -<HR><H2><A NAME="simple">Simple name-based 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.</P> - -<P>The first half shows some other configuration options that are -needed to make the <CODE>mod_rewrite</CODE> part work as expected; the -second half uses <CODE>mod_rewrite</CODE> to do the actual work. Some -care is taken to do a per-dynamic-virtual-host equivalent of -<CODE>ScriptAlias</CODE>.</P> - -<PRE> -# dynamic ServerName -UseCanonicalName Off - -# splittable logs -LogFormat "%{SERVER_NAME}e %h %l %u %t \"%r\" %s %b" vcommon -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 -</Directory> - -# now for the hard bit - -RewriteEngine On - -# a ServerName derived from a Host: header may be any case at all -RewriteMap lowercase int:tolower - -## deal with normal documents first: -# allow Alias /icons/ to work - repeat for other aliases -RewriteCond %{REQUEST_URI} !^/icons/ -# allow CGIs to work -RewriteCond %{REQUEST_URI} !^/cgi-bin/ -# do the magic -RewriteRule ^/(.*)$ /www/hosts/${lowercase:%{SERVER_NAME}}/docs/$1 - -## and now deal with CGIs - we have to force a MIME type -RewriteCond %{REQUEST_URI} ^/cgi-bin/ -RewriteRule ^/(.*)$ /www/hosts/${lowercase:%{SERVER_NAME}}/cgi-bin/$1 [T=application/x-httpd-cgi] - -# that's it! -</PRE> - - -<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 slightly more complicated rewriting rules 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> -RewriteEngine on - -RewriteMap lowercase int:tolower - -# allow CGIs to work -RewriteCond %{REQUEST_URI} !^/cgi-bin/ - -# check the hostname is right so that the RewriteRule works -RewriteCond ${lowercase:%{HTTP_HOST}} ^www\.[a-z-]+\.isp\.com$ - -# concatenate the virtual host name onto the start of the URI -# the [C] means do the next rewrite on the result of this one -RewriteRule ^(.+) ${lowercase:%{HTTP_HOST}}$1 [C] - -# now create the real file name -RewriteRule ^www\.([a-z-]+)\.isp\.com/(.*) /home/$1/$2 - -# 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> - -<P>This arrangement uses a separate configuration file to specify the -translation from virtual host to document root. This provides more -flexibility but requires more configuration.</P> - -<P>The <CODE>vhost.map</CODE> file contains something like this: -<PRE> -www.customer-1.com /www/customers/1 -www.customer-2.com /www/customers/2 -# ... -www.customer-N.com /www/customers/N -</PRE> -</P> - -<P>The <CODE>http.conf</CODE> contains this: -<PRE> -RewriteEngine on - -RewriteMap lowercase int:tolower - -# define the map file -RewriteMap vhost txt:/www/conf/vhost.map - -# deal with aliases as above -RewriteCond %{REQUEST_URI} !^/icons/ -RewriteCond %{REQUEST_URI} !^/cgi-bin/ -RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$ -# this does the file-based remap -RewriteCond ${vhost:%1} ^(/.*)$ -RewriteRule ^/(.*)$ %1/docs/$1 - -RewriteCond %{REQUEST_URI} ^/cgi-bin/ -RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$ -RewriteCond ${vhost:%1} ^(/.*)$ -RewriteRule ^/(.*)$ %1/cgi-bin/$1 -</PRE> -</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 rewrite 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 -convential <CODE><VirtualHost></CODE> configuration -sections.</P> - -<PRE> -UseCanonicalName Off - -LogFormat "%{SERVER_NAME}e %h %l %u %t \"%r\" %s %b" vcommon -CustomLog logs/access_log vcommon - -<Directory /www/commercial> - Options FollowSymLinks ExecCGI - AllowOverride All -</Directory> - -<Directory /www/homepages> - Options FollowSymLinks - AllowOverride None -</Directory> - -<VirtualHost 111.22.33.44> - ServerName www.commercial.isp.com - - RewriteEngine On - RewriteMap lowercase int:tolower - - RewriteCond %{REQUEST_URI} !^/icons/ - RewriteCond %{REQUEST_URI} !^/cgi-bin/ - RewriteRule ^/(.*)$ /www/commercial/${lowercase:%{SERVER_NAME}}/docs/$1 - - RewriteCond %{REQUEST_URI} ^/cgi-bin/ - RewriteRule ^/(.*)$ /www/commercial/${lowercase:%{SERVER_NAME}}/cgi-bin/$1 [T=application/x-httpd-cgi] -</VirtualHost> - -<VirtualHost 111.22.33.45> - ServerName www.homepages.isp.com - - RewriteEngine on - RewriteMap lowercase int:tolower - - RewriteCond %{REQUEST_URI} !^/cgi-bin/ - - RewriteCond ${lowercase:%{HTTP_HOST}} ^www\.[a-z-]+\.isp\.com$ - RewriteRule ^(.+) ${lowercase:%{HTTP_HOST}}$1 [C] - RewriteRule ^www\.([a-z-]+)\.isp\.com/(.*) /www/homepages/$1/$2 - - ScriptAlias /cgi-bin/ /www/std-cgi/ -</VirtualHost> -</PRE> - - -<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> diff --git a/docs/manual/vhosts/name-based.html b/docs/manual/vhosts/name-based.html deleted file mode 100644 index 238cf5c721..0000000000 --- a/docs/manual/vhosts/name-based.html +++ /dev/null @@ -1,164 +0,0 @@ -<!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>While the approach with IP-based virtual hosts works very well, -it is not the most elegant solution, because a dedicated IP address -is needed for every virtual host and it 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 name-based 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 client must support this part of the -protocol. The latest versions of most browsers do, but there are still -old browsers in use who 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. 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> - ServerName www.domain.tld - DocumentRoot /www/domain - </VirtualHost> - - <VirtualHost 111.22.33.44> - ServerName www.otherdomain.tld - DocumentRoot /www/otherdomain - </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 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 to use 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>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> - -<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>Example configuration: - -<PRE> - NameVirtualHost 111.22.33.44 - - <VirtualHost 111.22.33.44> - ServerName www.domain.tld - ServerPath /domain - DocumentRoot /web/domain - </VirtualHost> -</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> diff --git a/docs/manual/vhosts/name-based.html.en b/docs/manual/vhosts/name-based.html.en deleted file mode 100644 index 238cf5c721..0000000000 --- a/docs/manual/vhosts/name-based.html.en +++ /dev/null @@ -1,164 +0,0 @@ -<!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>While the approach with IP-based virtual hosts works very well, -it is not the most elegant solution, because a dedicated IP address -is needed for every virtual host and it 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 name-based 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 client must support this part of the -protocol. The latest versions of most browsers do, but there are still -old browsers in use who 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. 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> - ServerName www.domain.tld - DocumentRoot /www/domain - </VirtualHost> - - <VirtualHost 111.22.33.44> - ServerName www.otherdomain.tld - DocumentRoot /www/otherdomain - </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 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 to use 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>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> - -<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>Example configuration: - -<PRE> - NameVirtualHost 111.22.33.44 - - <VirtualHost 111.22.33.44> - ServerName www.domain.tld - ServerPath /domain - DocumentRoot /web/domain - </VirtualHost> -</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> diff --git a/docs/manual/vhosts/vhosts-in-depth.html b/docs/manual/vhosts/vhosts-in-depth.html deleted file mode 100644 index 23d8e919a1..0000000000 --- a/docs/manual/vhosts/vhosts-in-depth.html +++ /dev/null @@ -1,396 +0,0 @@ -<!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: - -<BLOCKQUOTE><PRE> - <VirtualHost A> - ... - </VirtualHost> - - <VirtualHost B> - ... - </VirtualHost> - - <VirtualHost C> - ... - </VirtualHost> -</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: - -<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> diff --git a/docs/manual/vhosts/virtual-host.html b/docs/manual/vhosts/virtual-host.html deleted file mode 100644 index aa81fad91e..0000000000 --- a/docs/manual/vhosts/virtual-host.html +++ /dev/null @@ -1,208 +0,0 @@ -<!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> - struct rlimit rlp; - - rlp.rlim_cur = rlp.rlim_max = 512; - if (setrlimit(RLIMIT_NPROC, &rlp)) { - 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> |