| <?xml version='1.0' encoding='UTF-8' ?> |
| <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd"> |
| <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?> |
| <!-- $LastChangedRevision$ --> |
| |
| <!-- |
| Licensed to the Apache Software Foundation (ASF) under one or more |
| contributor license agreements. See the NOTICE file distributed with |
| this work for additional information regarding copyright ownership. |
| The ASF licenses this file to You under the Apache License, Version 2.0 |
| (the "License"); you may not use this file except in compliance with |
| the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| |
| <manualpage metafile="name-based.xml.meta"> |
| <parentdocument href="./">Virtual Hosts</parentdocument> |
| <title>Name-based Virtual Host Support</title> |
| |
| <summary> |
| <p>This document describes when and how to use name-based virtual hosts.</p> |
| </summary> |
| |
| <seealso><a href="ip-based.html">IP-based Virtual Host Support</a></seealso> |
| <seealso><a href="details.html">An In-Depth Discussion of Virtual Host Matching</a></seealso> |
| <seealso><a href="mass.html">Dynamically configured mass virtual hosting</a></seealso> |
| <seealso><a href="examples.html">Virtual Host examples for common setups</a></seealso> |
| |
| <section id="namevip"><title>Name-based vs. IP-based Virtual Hosts</title> |
| |
| <p><a href="ip-based.html">IP-based virtual hosts</a> use the IP address of the connection to |
| determine the correct virtual host to serve. Therefore you need to |
| have a separate IP address for each host.</p> |
| |
| <p>With name-based virtual hosting, the server relies on the client to |
| report the hostname as part of the HTTP headers. Using this technique, |
| many different hosts can share the same IP address.</p> |
| |
| <p>Name-based virtual hosting is usually simpler, since you need |
| only configure your DNS server to map each hostname to the correct |
| IP address and then configure the Apache HTTP Server to recognize |
| the different hostnames. Name-based virtual hosting also eases |
| the demand for scarce IP addresses. Therefore you should use |
| name-based virtual hosting unless you are using equipment |
| that explicitly demands IP-based hosting. Historical reasons for |
| IP-based virtual hosting based on client support are no longer |
| applicable to a general-purpose web server.</p> |
| |
| <p> Name-based virtual hosting builds off of the IP-based virtual host |
| selection algorithm, meaning that searches for the proper server name |
| occur only between virtual hosts that have the best IP-based address.</p> |
| |
| </section> |
| |
| <section id="alg"><title>How the server selects the proper name-based virtual host</title> |
| |
| <p>It is important to recognize that the first step in name-based virtual |
| host resolution is IP-based resolution. Name-based virtual host |
| resolution only chooses the most appropriate name-based virtual host |
| after narrowing down the candidates to the best IP-based match. Using a wildcard (*) |
| for the IP address in all of the VirtualHost directives makes this |
| IP-based mapping irrelevant.</p> |
| |
| <p>When a request arrives, the server will find the best (most specific) matching |
| <directive type="section" module="core">VirtualHost</directive> argument based on |
| the IP address and port used by the request. If there is more than one virtual host |
| containing this best-match address and port combination, Apache will further |
| compare the <directive module="core" >ServerName</directive> and <directive |
| module="core">ServerAlias</directive> directives to the server name |
| present in the request.</p> |
| |
| <p>If you omit the <directive module="core">ServerName</directive> |
| directive from any name-based virtual host, the server will default |
| to a fully qualified domain name (FQDN) derived from the system hostname. |
| This implicitly set server name can lead to counter-intuitive virtual host |
| matching and is discouraged.</p> |
| |
| <section id="defaultvhost"><title>The default name-based vhost for an IP and port combination </title> |
| <p> If no matching ServerName or ServerAlias is found in the set of |
| virtual hosts containing the most specific matching IP address and port |
| combination, then <strong>the first listed virtual host</strong> that |
| matches that will be used.</p></section> |
| </section> |
| |
| <section id="using"><title>Using Name-based Virtual Hosts</title> |
| |
| <related> |
| <modulelist> |
| <module>core</module> |
| </modulelist> |
| |
| <directivelist> |
| <directive module="core">DocumentRoot</directive> |
| <directive module="core">ServerAlias</directive> |
| <directive module="core">ServerName</directive> |
| <directive module="core" type="section">VirtualHost</directive> |
| </directivelist> |
| </related> |
| |
| <p>The first step is to create a <directive type="section" |
| module="core">VirtualHost</directive> block for |
| each different host that you would like to serve. Inside each <directive type="section" |
| module="core">VirtualHost</directive> block, you will need at minimum a |
| <directive module="core">ServerName</directive> directive to designate |
| which host is served and a <directive module="core">DocumentRoot</directive> |
| directive to show where in the filesystem the content for that host |
| lives.</p> |
| |
| <note><title>Main host goes away</title> |
| <p> Any request that doesn't match an existing <directive type="section" |
| module="core">VirtualHost</directive> is handled by the global |
| server configuration, regardless of the hostname or ServerName.</p> |
| |
| <p> When you add a name-based virtual host to an existing server, and |
| the virtual host arguments match preexisting IP and port combinations, |
| requests will now be handled by an explicit virtual host. In this case, |
| it's usually wise to create a <a href="#defaultvhost">default virtual host</a> |
| with a <directive module="core">ServerName</directive> matching that of |
| the base server. New domains on the same interface and port, but |
| requiring separate configurations, can then be added as subsequent (non-default) |
| virtual hosts.</p> |
| </note> |
| |
| <note><title>ServerName inheritance</title> |
| <p> It is best to always explicitly list a <directive module="core" |
| >ServerName</directive> in every name-based virtual host.</p> |
| <p>If a <directive module="core">VirtualHost</directive> doesn't specify |
| a <directive module="core">ServerName</directive>, a server name will be |
| inherited from the base server configuration. If no server name was |
| specified globally, one is detected at startup through reverse DNS resolution |
| of the first listening address. In either case, this inherited server name |
| will influence name-based virtual host resolution, so it is best to always |
| explicitly list a <directive module="core">ServerName</directive> in every |
| name-based virtual host.</p> |
| </note> |
| |
| <p>For example, suppose that you are serving the domain |
| <code>www.example.com</code> and you wish to add the virtual host |
| <code>other.example.com</code>, which points at the same IP address. |
| Then you simply add the following to <code>httpd.conf</code>:</p> |
| |
| <highlight language="config"> |
| <VirtualHost *:80> |
| # This first-listed virtual host is also the default for *:80 |
| ServerName www.example.com |
| ServerAlias example.com |
| DocumentRoot "/www/domain" |
| </VirtualHost> |
| |
| <VirtualHost *:80> |
| ServerName other.example.com |
| DocumentRoot "/www/otherdomain" |
| </VirtualHost> |
| </highlight> |
| |
| <p>You can alternatively specify an explicit IP address in place of the |
| <code>*</code> in <directive type="section" module="core" |
| >VirtualHost</directive> directives. For example, you might want to do this |
| in order to run some name-based virtual hosts on one IP address, and either |
| IP-based, or another set of name-based virtual hosts on another address.</p> |
| |
| <p>Many servers want to be accessible by more than one name. This is |
| possible with the <directive module="core">ServerAlias</directive> |
| directive, placed inside the <directive type="section" module="core" |
| >VirtualHost</directive> section. For example in the first <directive |
| type="section" module="core">VirtualHost</directive> block above, the |
| <directive module="core">ServerAlias</directive> directive indicates that |
| the listed names are other names which people can use to see that same |
| web site:</p> |
| |
| <highlight language="config"> |
| ServerAlias example.com *.example.com |
| </highlight> |
| |
| <p>then requests for all hosts in the <code>example.com</code> domain will |
| be served by the <code>www.example.com</code> virtual host. The wildcard |
| characters <code>*</code> and <code>?</code> can be used to match names. |
| Of course, you can't just make up names and place them in <directive |
| module="core">ServerName</directive> or <code>ServerAlias</code>. You must |
| first have your DNS server properly configured to map those names to an IP |
| address associated with your server.</p> |
| |
| <p>Name-based virtual hosts for the best-matching set of <directive |
| type="section" module="core">virtualhost</directive>s are processed |
| in the order they appear in the configuration. The first matching <directive |
| module="core">ServerName</directive> or <directive module="core" |
| >ServerAlias</directive> is used, with no different precedence for wildcards |
| (nor for ServerName vs. ServerAlias). </p> |
| |
| <p>The complete list of names in the <directive module="core" |
| >VirtualHost</directive> |
| directive are treated just like a (non wildcard) |
| <directive module="core">ServerAlias</directive>.</p> |
| |
| <p>Finally, you can fine-tune the configuration of the virtual hosts |
| by placing other directives inside the <directive type="section" |
| module="core">VirtualHost</directive> containers. Most directives can be |
| placed in these containers and will then change the configuration only of |
| the relevant virtual host. To find out if a particular directive is allowed, |
| check the <a href="../mod/directive-dict.html#Context">Context</a> of the |
| directive. Configuration directives set in the <em>main server context</em> |
| (outside any <directive type="section" module="core">VirtualHost</directive> |
| container) will be used only if they are not overridden by the virtual host |
| settings.</p> |
| |
| </section> |
| |
| </manualpage> |