manual/vhosts/name-based.html

	name-based.html revision 85939515009c2c78e391236bf825ded8609f6a1a
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe<HTML><HEAD>
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe<TITLE>Apache name-based Virtual Hosts</TITLE>
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe</HEAD>
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe<BODY
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe BGCOLOR="#FFFFFF"
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe TEXT="#000000"
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe LINK="#0000FF"
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe VLINK="#000080"
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe ALINK="#FF0000"
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe>
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe<!--#include virtual="header.html" -->
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe<H1 ALIGN="CENTER">Apache name-based Virtual Host Support</H1>
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe<STRONG>See Also:</STRONG>
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe<A HREF="ip-based.html">IP-based Virtual Host Support</A>
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe<HR>
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe<H2>Name-based vs. IP-based virtual hosts</H2>
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe<P>While the approach with IP-based virtual hosts works very well,
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Loweit is not the most elegant solution, because a dedicated IP address
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Loweis needed for every virtual host and it is hard to implement on some
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowemachines. The <CODE>HTTP/1.1</CODE> protocol contains a method for the
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Loweserver to identify what name it is being addressed as. Apache 1.1 and
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowelater support this approach as well as the traditional
c10c16dec587a0662068f6e2991c29ed3a9db943Richard LoweIP-address-per-hostname method.</P>
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe<P>The benefits of using the new name-based virtual host support is a
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowepractically unlimited number of servers, ease of configuration and use, and
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowerequires no additional hardware or software.
c10c16dec587a0662068f6e2991c29ed3a9db943Richard LoweThe main disadvantage is that the client must support this part of the
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Loweprotocol. The latest versions of most browsers do, but there are still
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Loweold browsers in use who do not. This can cause problems, although a possible
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowesolution is addressed below.</P>
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe<H2>Using non-IP Virtual Hosts</H2>
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowe<P>Using the new virtual hosts is quite easy, and superficially looks
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowelike the old method. You simply add to one of the Apache configuration
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowefiles (most likely <CODE>httpd.conf</CODE> or <CODE>srm.conf</CODE>)
c10c16dec587a0662068f6e2991c29ed3a9db943Richard Lowecode similar to the following:</P>
<PRE>
    NameVirtualHost 111.22.33.44

    &lt;VirtualHost 111.22.33.44&gt;
    ServerName www.domain.tld
    DocumentRoot /web/domain
    &lt;/VirtualHost&gt;
</PRE>

<P>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.

<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 name
<SAMP>www.domain.tld</SAMP> points to the IP address
<SAMP>111.22.33.44</SAMP></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 &lt;VirtualHost&gt;s.  The "main server" will <b>never</b>
be served from the specified IP address.

<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.</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
<CITE>primary</CITE> name-based virtual host (the first virtual host
appearing in the configuration file for a specific IP address).</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 (e.g. "<SAMP>file.html</SAMP>" or
"<SAMP>/icons/image.gif</SAMP>" or links containing the prefacing
<SAMP>/domain/</SAMP>
(e.g. "<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>