name-based.html revision 2eaf662cbc81e823e8d9aeb8d54e69e63032493e
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<html xmlns="http://www.w3.org/1999/xhtml">
<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>
Virtual Host Support</a>
<hr />
<h2>Name-based vs. IP-based virtual hosts</h2>
<p>Early versions of HTTP (like many other protocols, e.g. FTP)
required a different IP address for each virtual host on the
server. On some platforms this can limit the number of virtual
hosts you can run, and because there are concerns about the
availability of IP addresses it is strongly discouraged by the
registraries (ARIN, RIPE, and APNIC).</p>
identify what name it is being addressed as. Apache 1.1 and
later support this approach as well as the old
IP-address-per-hostname method.</p>
<p>The benefits of using the name-based virtual hosts is a
practically unlimited number of servers, ease of configuration
and use, and it requires no additional hardware or software.
The main disadvantage is that the client must support this part
of the protocol. Almost all browsers do, but there are still
tiny numbers of very old browsers in use which do not. This can
cause problems, although a possible solution is addressed
below.</p>
<h2>Using name-based virtual hosts</h2>
<p>Using name-based virtual hosts is quite easy, and
superficially looks like the old method. The notable difference
between IP-based and name-based virtual host configuration is
the <a
directive which specifies an IP address that should be used as
a target for name-based virtual hosts, or the wildcard
<code>*</code> to indicate that the server only does name-based
virtual hosting (no IP-based virtual hosting).</p>
your server. Then you simply add to one of the Apache
<pre>
NameVirtualHost *
<VirtualHost *>
ServerName www.domain.tld
</VirtualHost>
<VirtualHost *>
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
address.</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 specify a wildcard then the "main server" isn't used at
all. If you start to use virtual hosts you should stop using
the "main server" as an independent server and rather use it as
a place for configuration directives that are common for all
your virtual hosts. In other words, you should add a
<VirtualHost> section for <em>every</em> server
(hostname) you want to maintain on your server.</p>
<p>Additionally, many servers may wish to be accessible by more
than one name. For example, the example server might want to be
to the same server. In fact, one might want it so that all
server. This is possible with the <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
directive, albeit a slightly cumbersome one:</p>
<p>Example configuration:</p>
<pre>
NameVirtualHost 111.22.33.44
<VirtualHost 111.22.33.44>
ServerName www.domain.tld
ServerPath /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
pages can be accessed as
although clients sending a <samp>Host:</samp> header can also
<p>In order to make this work, put a link on your primary
virtual host's page to
host's pages, be sure to use either purely relative links
<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>
configuration example</a></p>
<!--#include virtual="footer.html" -->
</body>
</html>