Removing 1.3 refs from 2.x docs

<manualpage metafile="mass.xml.meta">

<parentdocument href="./">Virtual Hosts</parentdocument>

   <title>Dynamically configured mass virtual hosting</title>

   <title>Dynamically Configured Mass Virtual Hosting</title>

<summary>

    <p>This document describes how to efficiently serve an

    arbitrary number of virtual hosts with Apache. <!--

                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.

                -->

    arbitrary number of virtual hosts with the Apache httpd webserver.

    </p>

</summary>

</example>

    <p>The basic idea is to replace all of the static

    <code>&lt;VirtualHost&gt;</code> configuration with a mechanism

    that works it out dynamically. This has a number of

    <code>&lt;VirtualHost&gt;</code> configurations with a mechanism

    that works them out dynamically. This has a number of

    advantages:</p>

    <ol>

      <li>Your configuration file is smaller so Apache starts

      faster and uses less memory.</li>

      <li>Your configuration file is smaller, so Apache starts

      more quickly and uses less memory.</li>

      <li>Adding virtual hosts is simply a matter of creating the

      appropriate directories in the filesystem and entries in the

      DNS - you don't need to reconfigure or restart Apache.</li>

    </ol>

    <p>The main disadvantage is that you cannot have a different

    log file for each virtual host; however if you have very many

    virtual hosts then doing this is dubious anyway because it eats

    file descriptors. It is better to log to a pipe or a fifo and

    arrange for the process at the other end to distribute the logs

    to the customers (it can also accumulate statistics, etc.).</p>

    <p>The main disadvantage is that you cannot have a different log file for

    each virtual host; however, if you have many virtual hosts, doing

    this can be a bad idea anyway, because of the number of file

    descriptors needed. It is better to log to a pipe or a fifo, and arrange for

    the process at the other end to distribute the logs to the customers.

    (This can also be used to accumulate statistics, etc.).</p>

</section>

    <p>A virtual host is defined by two pieces of information: its

    IP address, and the contents of the <code>Host:</code> header

    in the HTTP request. The dynamic mass virtual hosting technique

    is based on automatically inserting this information into the

    used here is based on automatically inserting this information into the

    pathname of the file that is used to satisfy the request. This

    is done most easily using <module>mod_vhost_alias</module>,

    but if you are using a version of Apache up to 1.3.6 then you

    must use <module>mod_rewrite</module>.

    can be most easily done by using <module>mod_vhost_alias</module> 

    with Apache 2.0. Alternatively, <module>mod_rewrite</module> can be used.

    Both of these modules are disabled by default; you must enable

    one of them when configuring and building Apache if you want to

    use this technique.</p>

    <p>A couple of things need to be `faked' to make the dynamic

    virtual host look like a normal one. The most important is the

    server name which is used by Apache to generate

    self-referential URLs, etc. It is configured with the

    server name, which is used by Apache to generate

    self-referential URLs etc. It is configured with the

    <code>ServerName</code> directive, and it is available to CGIs

    via the <code>SERVER_NAME</code> environment variable. The

    actual value used at run time is controlled by the <directive

    module="core">UseCanonicalName</directive>

    setting. With <code>UseCanonicalName Off</code> the server name

    comes from the contents of the <code>Host:</code> header in the

    request. With <code>UseCanonicalName DNS</code> it comes from a

    setting. With <code>UseCanonicalName Off</code>, the server name

    is taken from the contents of the <code>Host:</code> header in the

    request. With <code>UseCanonicalName DNS</code>, it is taken from a

    reverse DNS lookup of the virtual host's IP address. The former

    setting is used for name-based dynamic virtual hosting, and the

    latter is used for IP-based hosting. If Apache cannot work out

    the server name because there is no <code>Host:</code> header

    or the DNS lookup fails then the value configured with

    the server name because there is no <code>Host:</code> header,

    or the DNS lookup fails, then the value configured with

    <code>ServerName</code> is used instead.</p>

    <p>The other thing to `fake' is the document root (configured

    with <code>DocumentRoot</code> and available to CGIs via the

    <code>DOCUMENT_ROOT</code> environment variable). In a normal

    configuration this setting is used by the core module when

    configuration, this is used by the core module when

    mapping URIs to filenames, but when the server is configured to

    do dynamic virtual hosting that job is taken over by another

    do dynamic virtual hosting, that job must be taken over by another

    module (either <code>mod_vhost_alias</code> or

    <code>mod_rewrite</code>) which has a different way of doing

    <code>mod_rewrite</code>), which has a different way of doing

    the mapping. Neither of these modules is responsible for

    setting the <code>DOCUMENT_ROOT</code> environment variable so

    if any CGIs or SSI documents make use of it they will get a

    if any CGIs or SSI documents make use of it, they will get a

    misleading value.</p>

</section>

<section id="simple"><title>Simple dynamic virtual hosts</title>

<section id="simple"><title>Simple Dynamic Virtual Hosts</title>

    <p>This extract from <code>httpd.conf</code> implements the

    virtual host arrangement outlined in the <a

</section>

<section id="homepages"><title>A virtually hosted homepages system</title>

<section id="homepages"><title>A Virtually Hosted Homepages System</title>

    <p>This is an adjustment of the above system tailored for an

    <p>This is an adjustment of the above system, tailored for an

    ISP's homepages server. Using a slightly more complicated

    configuration we can select substrings of the server name to

    use in the filename so that e.g. the documents for

    configuration, we can select substrings of the server name to

    use in the filename so that, for example, the documents for

    <code>www.user.isp.com</code> are found in

    <code>/home/user/</code>. It uses a single <code>cgi-bin</code>

    directory instead of one per virtual host.</p>

</section>

<section id="combinations"><title>Using more than

    one virtual hosting system on the same server</title>

<section id="combinations"><title>Using Multiple Virtual

	Hosting Systems on the Same Server</title>

    <p>With more complicated setups you can use Apache's normal

    <p>With more complicated setups, you can use Apache's normal

    <code>&lt;VirtualHost&gt;</code> directives to control the

    scope of the various virtual hosting configurations. For

    example, you could have one IP address for homepages customers

    and another for commercial customers with the following setup.

    This can of course be combined with conventional

    example, you could have one IP address for general customers' homepages,

    and another for commercial customers, with the following setup.

    This can, of course, be combined with conventional

    <code>&lt;VirtualHost&gt;</code> configuration sections.</p>

<example>

</section>

<section id="ipbased"><title>More efficient IP-based virtual hosting</title>

<section id="ipbased"><title>More Efficient IP-Based Virtual Hosting</title>

    <p>After <a href="#simple">the first example</a> I noted that

    it is easy to turn it into an IP-based virtual hosting setup.

    Unfortunately that configuration is not very efficient because

    it requires a DNS lookup for every request. This can be avoided

    by laying out the filesystem according to the IP addresses

    themselves rather than the corresponding names and changing the

    logging similarly. Apache will then usually not need to work

    out the server name and so incur a DNS lookup.</p>

    <p>The configuration changes suggested to turn <a href="#simple">the first

    example</a> into an IP-based virtual hosting setup result in

    a rather inefficient setup. A new DNS lookup is required for every

    request. To avoid this overhead, the filesystem can be arranged to

    correspond to the IP addresses, instead of to the host names, thereby

    negating the need for a DNS lookup. Logging will also have to be adjusted

    to fit this system.</p>

<example>

# get the server name from the reverse DNS of the IP address<br />

</section>

<section id="oldversion"><title>Using older versions of Apache</title>

    <p>The examples above rely on <code>mod_vhost_alias</code>

    which appeared after version 1.3.6. If you are using a version

    of Apache without <code>mod_vhost_alias</code> then you can

    implement this technique with <code>mod_rewrite</code> as

    illustrated below, but only for Host:-header-based virtual

    hosts.</p>

    <p>In addition there are some things to beware of with logging.

    Apache 1.3.6 is the first version to include the

    <code>%V</code> log format directive; in versions 1.3.0 - 1.3.3

    the <code>%v</code> option did what <code>%V</code> does;

    version 1.3.4 has no equivalent. In all these versions of

    Apache the <code>UseCanonicalName</code> directive can appear

    in <code>.htaccess</code> files which means that customers can

    cause the wrong thing to be logged. Therefore the best thing to

    do is use the <code>%{Host}i</code> directive which logs the

    <code>Host:</code> header directly; note that this may include

    <code>:port</code> on the end which is not the case for

    <code>%V</code>.</p>

</section>

<section id="simple.rewrite"><title>Simple dynamic

    virtual hosts using <code>mod_rewrite</code></title>

<section id="simple.rewrite"><title>Simple Dynamic

    Virtual Hosts Using <module>mod_rewrite</module></title>

    <p>This extract from <code>httpd.conf</code> does the same

    thing as <a href="#simple">the first example</a>. The first

    half is very similar to the corresponding part above but with

    some changes for backward compatibility and to make the

    half is very similar to the corresponding part above, except for

    some changes, required for backward compatibility and to make the

    <code>mod_rewrite</code> part work properly; the second half

    configures <code>mod_rewrite</code> to do the actual work.</p>

    <p>There are a couple of especially tricky bits: By default,

    <code>mod_rewrite</code> runs before the other URI translation

    modules (<code>mod_alias</code> etc.) so if they are used then

    <code>mod_rewrite</code> must be configured to accommodate

    them. Also, some magic must be performed to do a

    <p>There are a couple of especially tricky bits: by default,

    <code>mod_rewrite</code> runs before other URI translation

    modules (<code>mod_alias</code> etc.) - so if you wish to use these modules,    <code>mod_rewrite</code> must be configured to accommodate

    them. Also, some magic is required to do a

    per-dynamic-virtual-host equivalent of

    <code>ScriptAlias</code>.</p>

</section>

<section id="homepages.rewrite"><title>A

    homepages system using <code>mod_rewrite</code></title>

    Homepages System Using <code>mod_rewrite</code></title>

    <p>This does the same thing as <a href="#homepages">the second

    example</a>.</p>

</section>

<section id="xtra-conf"><title>Using a separate virtual

    host configuration file</title>

<section id="xtra-conf"><title>Using a Separate Virtual

    Host Configuration File</title>

    <p>This arrangement uses more advanced <code>mod_rewrite</code>

    features to get the translation from virtual host to document

    root from a separate configuration file. This provides more

    flexibility but requires more complicated configuration.</p>

    <p>This arrangement uses more advanced <module>mod_rewrite</module>

    features to work out the translation from virtual host to document

    root, from a separate configuration file. This provides more

    flexibility, but requires more complicated configuration.</p>

    <p>The <code>vhost.map</code> file contains something like

    <p>The <code>vhost.map</code> file should look something like

    this:</p>

<example>

www.customer-N.com  /www/customers/N<br />

</example>

    <p>The <code>http.conf</code> contains this:</p>

    <p>The <code>httpd.conf</code> should contain the following:</p>

<example>

RewriteEngine on<br />