325N/A<!
DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 325N/A <
title>Apache name-based Virtual Hosts</
title>
325N/A <!-- Background white, links blue (unvisited), navy (visited), red (active) --> 325N/A <
body bgcolor="#FFFFFF" text="#000000" link="#0000FF" 325N/A vlink="#000080" alink="#FF0000">
325N/A <
h1 align="CENTER">Apache name-based Virtual Host Support</
h1>
325N/A Virtual Host Support</
a>
325N/A <
h2>Name-based vs. IP-based virtual hosts</
h2>
325N/A <
p>Early versions of HTTP (like many other protocols,
e.g. FTP)
325N/A required a different IP address for each virtual host on the
325N/A server. On some platforms this can limit the number of virtual
325N/A hosts you can run, and because there are concerns about the
325N/A availability of IP addresses it is strongly discouraged by the
325N/A registraries (ARIN, RIPE, and APNIC).</
p>
325N/A <
p>The <
code>
HTTP/
1.1</
code> protocol, and a common extension
325N/A to <
code>
HTTP/
1.0</
code>, includes a method for the server to
325N/A identify what name it is being addressed as. Apache 1.1 and
325N/A later support this approach as well as the old
325N/A IP-address-per-hostname method.</
p>
325N/A <
p>The benefits of using the name-based virtual hosts is a
325N/A practically unlimited number of servers, ease of configuration
325N/A and use, and it requires no additional hardware or software.
325N/A The main disadvantage is that the client must support this part
325N/A of the protocol. Almost all browsers do, but there are still
325N/A tiny numbers of very old browsers in use which do not. This can
325N/A cause problems, although a possible solution is addressed
325N/A <
h2>Using name-based virtual hosts</
h2>
325N/A <
p>Using name-based virtual hosts is quite easy, and
325N/A superficially looks like the old method. The notable difference
325N/A between IP-based and name-based virtual host configuration is
325N/A directive which specifies an IP address that should be used as
325N/A a target for name-based virtual hosts, or the wildcard
325N/A <
code>*</
code> to indicate that the server only does name-based
325N/A virtual hosting (no IP-based virtual hosting).</
p>
325N/A your server. Then you simply add to one of the Apache
<
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
<
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
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 <VirtualHost> section. For
<
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:</
p>
NameVirtualHost 111.22.33.44
<VirtualHost 111.22.33.44>
<
p>What does this mean? It means that a request for any URI
beginning with "<
samp>/domain</
samp>" will be served from the
although clients sending a <
samp>Host:</
samp> header can also
<
p>In order to make this work, put a link on your primary
host's pages, be sure to use either purely relative links
prefacing <
samp>/domain/</
samp> (<
em>
e.g.</
em>,
<
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>
