name-based.html.en revision a7e8af9c27bc85079c0f80a3b4fa3af90196b6dd
b2423f1f436f847d9fc96a63679be2b5552b6bafLennart Poettering<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
b2423f1f436f847d9fc96a63679be2b5552b6bafLennart Poettering<HTML><HEAD>
b2423f1f436f847d9fc96a63679be2b5552b6bafLennart Poettering<TITLE>Apache name-based Virtual Hosts</TITLE>
5430f7f2bc7330f3088b894166bf3524a067e3d8Lennart Poettering</HEAD>
5430f7f2bc7330f3088b894166bf3524a067e3d8Lennart Poettering
b2423f1f436f847d9fc96a63679be2b5552b6bafLennart Poettering<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
b2423f1f436f847d9fc96a63679be2b5552b6bafLennart Poettering<BODY
b2423f1f436f847d9fc96a63679be2b5552b6bafLennart Poettering BGCOLOR="#FFFFFF"
b2423f1f436f847d9fc96a63679be2b5552b6bafLennart Poettering TEXT="#000000"
b2423f1f436f847d9fc96a63679be2b5552b6bafLennart Poettering LINK="#0000FF"
b2423f1f436f847d9fc96a63679be2b5552b6bafLennart Poettering VLINK="#000080"
4bb2357f77c875976de5e238a5783e4e136b37b5Lennart Poettering ALINK="#FF0000"
e096bf2f95c1cb553bb6f3ea370d450397e441e6Lennart Poettering>
5cd6eef69b926175b889799d80bd9deb33a904d1Lennart Poettering<!--#include virtual="header.html" -->
adf70c5e4e6673353b8d702baee4e1d21eb05dfeKay Sievers<H1 ALIGN="CENTER">Apache name-based Virtual Host Support</H1>
adf70c5e4e6673353b8d702baee4e1d21eb05dfeKay Sievers
adf70c5e4e6673353b8d702baee4e1d21eb05dfeKay Sievers<STRONG>See Also:</STRONG>
adf70c5e4e6673353b8d702baee4e1d21eb05dfeKay Sievers<A HREF="ip-based.html">IP-based Virtual Host Support</A>
adf70c5e4e6673353b8d702baee4e1d21eb05dfeKay Sievers
b2423f1f436f847d9fc96a63679be2b5552b6bafLennart Poettering<HR>
b2423f1f436f847d9fc96a63679be2b5552b6bafLennart Poettering
b2423f1f436f847d9fc96a63679be2b5552b6bafLennart Poettering<H2>Name-based vs. IP-based virtual hosts</H2>
449ddb2d23a63ca4c8cd70d13a070fba87c1fb30Lennart Poettering
b2423f1f436f847d9fc96a63679be2b5552b6bafLennart Poettering<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>
<P>The <CODE>HTTP/1.1</CODE> protocol, and a common extension to
<CODE>HTTP/1.0</CODE>, includes 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 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 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, or the wildcard <CODE>*</CODE> to
indicate that the server only does name-based virtual hosting (no
IP-based virtual hosting).</P>
<P>For example, suppose that both <SAMP>www.domain.tld</SAMP> and
<SAMP>www.otherdomain.tld</SAMP> point at the IP address of your
server. 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 *
&lt;VirtualHost *&gt;
ServerName www.domain.tld
DocumentRoot /www/domain
&lt;/VirtualHost&gt;
&lt;VirtualHost *&gt;
ServerName www.otherdomain.tld
DocumentRoot /www/otherdomain
&lt;/VirtualHost&gt;
</PRE>
<P>Of course, any additional directives can (and should) be placed
into the <CODE>&lt;VirtualHost&gt;</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 right IP address.
<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 &lt;VirtualHost&gt;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 &lt;VirtualHost&gt; 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 &lt;VirtualHost&gt; 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
&lt;VirtualHost 111.22.33.44&gt;
ServerName www.domain.tld
ServerPath /domain
DocumentRoot /web/domain
&lt;/VirtualHost&gt;
</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>