mirror of
https://github.com/apache/httpd.git
synced 2026-01-06 09:01:14 +03:00
PR 50396 Historical reasons for using IP-based virtualhosting no longer deserve to be featured in our docs. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1066434 13f79535-47bb-0310-9956-ffa450edef68
188 lines
9.1 KiB
XML
188 lines
9.1 KiB
XML
<?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>
|
|
|
|
<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>
|
|
|
|
<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>
|
|
|
|
<example>
|
|
<VirtualHost *:80><br />
|
|
<indent>
|
|
# This first-listed virtual host is also the default for *:80
|
|
ServerName www.example.com<br />
|
|
ServerAlias example.com *.example.com<br />
|
|
DocumentRoot /www/domain<br />
|
|
</indent>
|
|
</VirtualHost><br />
|
|
<br />
|
|
<VirtualHost *:80><br />
|
|
<indent>ServerName other.example.com<br />
|
|
DocumentRoot /www/otherdomain<br />
|
|
</indent>
|
|
</VirtualHost><br />
|
|
</example>
|
|
|
|
<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>
|
|
|
|
<example>
|
|
ServerAlias example.com *.example.com
|
|
</example>
|
|
|
|
<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>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>
|