]> granicus.if.org Git - apache/blob - docs/manual/vhosts/name-based.html
A truly mighty mod normalising HTML tags to uppercase, and
[apache] / docs / manual / vhosts / name-based.html
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
2 <HTML><HEAD>
3 <TITLE>Apache name-based Virtual Hosts</TITLE>
4 </HEAD>
5
6 <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
7 <BODY
8  BGCOLOR="#FFFFFF"
9  TEXT="#000000"
10  LINK="#0000FF"
11  VLINK="#000080"
12  ALINK="#FF0000"
13 >
14 <!--#include virtual="header.html" -->
15 <h1 ALIGN="CENTER">Apache name-based Virtual Host Support</H1>
16
17 <STRONG>See Also:</STRONG>
18 <A HREF="ip-based.html">IP-based Virtual Host Support</A>
19
20 <HR>
21
22 <h2>Name-based vs. IP-based virtual hosts</h2>
23
24 <P>While the approach with IP-based virtual hosts works very well,
25 it is not the most elegant solution, because a dedicated IP address
26 is needed for every virtual host and it is hard to implement on some
27 machines. The <CODE>HTTP/1.1</CODE> protocol contains a method for the
28 server to identify what name it is being addressed as. Apache 1.1 and
29 later support this approach as well as the traditional
30 IP-address-per-hostname method.</P>
31
32 <P>The benefits of using the new name-based virtual host support is a
33 practically unlimited number of servers, ease of configuration and use, and
34 requires no additional hardware or software. 
35 The main disadvantage is that the client must support this part of the
36 protocol. The latest versions of most browsers do, but there are still
37 old browsers in use who do not. This can cause problems, although a possible
38 solution is addressed below.</P>
39
40 <h2>Using non-IP Virtual Hosts</h2>
41
42 <P>Using the new virtual hosts is quite easy, and superficially looks
43 like the old method. You simply add to one of the Apache configuration
44 files (most likely <CODE>httpd.conf</CODE> or <CODE>srm.conf</CODE>)
45 code similar to the following:</P>
46 <PRE>
47     NameVirtualHost 111.22.33.44
48
49     &lt;VirtualHost 111.22.33.44&gt;
50     ServerName www.domain.tld
51     DocumentRoot /web/domain
52     &lt;/VirtualHost&gt;
53 </PRE>
54
55 <P>The notable difference between IP-based and name-based virtual host
56 configuration is the
57 <A HREF="../mod/core.html#namevirtualhost"><CODE>NameVirtualHost</CODE></A>
58 directive which specifies an IP address that should be used as a target for
59 name-based virtual hosts.
60
61 <P>Of course, any additional directives can (and should) be placed
62 into the <CODE>&lt;VirtualHost&gt;</CODE> section. To make this work,
63 all that is needed is to make sure that the name
64 <SAMP>www.domain.tld</SAMP> is an alias (CNAME) pointing to the IP address
65 <SAMP>111.22.33.44</SAMP></P>
66
67 <P>Additionally, many servers may wish to be accessible by more than
68 one name. For example, the example server might want to be accessible
69 as <CODE>domain.tld</CODE>, or <CODE>www2.domain.tld</CODE>, assuming
70 the IP addresses pointed to the same server. In fact, one might want it
71 so that all addresses at <CODE>domain.tld</CODE> were picked up by the
72 server. This is possible with the
73 <A HREF="../mod/core.html#serveralias"><CODE>ServerAlias</CODE></A>
74 directive, placed inside the &lt;VirtualHost&gt; section. For
75 example:</P>
76
77 <PRE>
78     ServerAlias domain.tld *.domain.tld
79 </PRE>
80
81 <P>Note that you can use <CODE>*</CODE> and <CODE>?</CODE> as wild-card
82 characters.</P>
83
84 <P>You also might need <CODE>ServerAlias</CODE> if you are
85 serving local users who do not always include the domain name.
86 For example, if local users are
87 familiar with typing "www" or "www.foobar" then you will need to add
88 <CODE>ServerAlias www www.foobar</CODE>.  It isn't possible for the
89 server to know what domain the client uses for their name resolution
90 because the client doesn't provide that information in the request.</P>
91
92 <h2>Compatibility with Older Browsers</h2>
93
94 <P>As mentioned earlier, there are still some clients in use who
95 do not send the required data for the name-based virtual hosts to work
96 properly. These clients will always be sent the pages from the
97 <CITE>primary</CITE> name-based virtual host (the first virtual host
98 appearing in the configuration file for a specific IP address).</P>
99
100 <P>There is a possible workaround with the
101 <A HREF="../mod/core.html#serverpath"><CODE>ServerPath</CODE></A>
102 directive, albeit a slightly cumbersome one:</P>
103
104 <P>Example configuration:
105
106 <PRE>
107     NameVirtualHost 111.22.33.44
108
109     &lt;VirtualHost 111.22.33.44&gt;
110     ServerName www.domain.tld
111     ServerPath /domain
112     DocumentRoot /web/domain
113     &lt;/VirtualHost&gt;
114 </PRE>
115
116 <P>What does this mean? It means that a request for any URI beginning
117 with "<SAMP>/domain</SAMP>" will be served from the virtual host
118 <SAMP>www.domain.tld</SAMP> This means that the pages can be accessed as
119 <CODE>http://www.domain.tld/domain/</CODE> for all clients, although
120 clients sending a <SAMP>Host:</SAMP> header can also access it as
121 <CODE>http://www.domain.tld/</CODE>.</P>
122
123 <P>In order to make this work, put a link on your primary virtual host's page
124 to <SAMP>http://www.domain.tld/domain/</SAMP>
125 Then, in the virtual host's pages, be sure to use either purely
126 relative links (e.g. "<SAMP>file.html</SAMP>" or
127 "<SAMP>../icons/image.gif</SAMP>" or links containing the prefacing
128 <SAMP>/domain/</SAMP>
129 (e.g. "<SAMP>http://www.domain.tld/domain/misc/file.html</SAMP>" or
130 "<SAMP>/domain/misc/file.html</SAMP>").</P>
131
132 <P>This requires a bit of
133 discipline, but adherence to these guidelines will, for the most part,
134 ensure that your pages will work with all browsers, new and old.</P>
135
136 <P>See also: <A HREF="examples.html#serverpath">ServerPath configuration
137 example</A></P>
138
139 <!--#include virtual="footer.html" -->
140 </BODY>
141 </HTML>