summaryrefslogtreecommitdiff
path: root/APACHE_1_3_42/htdocs/manual/vhosts/host.html
blob: e25ad6cfd04734d69bf1eccf4e93b34a7cd686f9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta name="generator" content="HTML Tidy, see www.w3.org" />

    <title>Apache non-IP 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 non-IP Virtual Hosts</h1>
    <strong>See Also:</strong> <a href="virtual-host.html">Virtual
    Host Support</a> 
    <hr />

    <h2>What is a Virtual Host</h2>

    <p>The "Virtual Host" refers to the practice of maintaining
    more than one server on one machine, as differentiated by their
    apparent hostname. For example, it is often desirable for
    companies sharing a web server to have their own domains, with
    web servers accessible as <code>www.company1.com</code> and
    <code>www.company2.com</code>, without requiring the user to
    know any extra path information.</p>

    <p>Apache was one of the first servers to support virtual hosts
    right out of the box, but since the base <code>HTTP</code>
    (HyperText Transport Protocol) standard does not allow any
    method for the server to determine the hostname it is being
    addressed as, Apache's virtual host support has required a
    separate IP address for each server. Documentation on using
    this approach (which still works very well) <a
    href="virtual-host.html">is available</a>.</p>

    <p>While the approach described above works, with the available
    IP address space growing smaller, and the number of domains
    increasing, it is not the most elegant solution, and is hard to
    implement on some machines. The <code>HTTP/1.1</code> protocol
    contains 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 traditional IP-address-per-hostname method.</p>

    <p>The benefits of using the new virtual host support is a
    practically unlimited number of servers, ease of configuration
    and use, and requires no additional hardware or software. The
    main disadvantage is that the user's browser must support this
    part of the protocol. The latest versions of many browsers
    (including Netscape Navigator 2.0 and later) do, but many
    browsers, especially older ones, do not. This can cause
    problems, although a possible solution is addressed below.</p>

    <h2>Using non-IP Virtual Hosts</h2>

    <p>Using the new virtual hosts is quite easy, and superficially
    looks like the old method. 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>
    &lt;VirtualHost www.apache.org&gt;
    ServerName www.apache.org
    DocumentRoot /usr/web/apache
    &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
    <code>www.apache.org</code> DNS entry points to the same IP
    address as the main server. Optionally, you could simply use
    that IP address in the &lt;VirtualHost&gt; entry.</p>

    <p>Additionally, many servers may wish to be accessible by more
    than one name. For example, the Apache server might want to be
    accessible as <code>apache.org</code>, or
    <code>ftp.apache.org</code>, assuming the IP addresses pointed
    to the same server. In fact, one might want it so that all
    addresses at <code>apache.org</code> were picked up by the
    server. This is possible with the <code>ServerAlias</code>
    directive, placed inside the &lt;VirtualHost&gt; section. For
    example:</p>
<pre>
    ServerAlias apache.org *.apache.org
</pre>

    <p>Note that you can use <code>*</code> and <code>?</code> as
    wild-card characters.</p>

    <p>You also might need ServerAlias 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.physics"
    then you will need to add <code>ServerAlias www
    www.physics</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>Security Considerations</h2>
    Apache allows all virtual hosts to be made accessible via the
    <code>Host:</code> header through all IP interfaces, even those
    which are configured to use different IP interfaces. For
    example, if the configuration for <code>www.foo.com</code>
    contained a virtual host section for <code>www.bar.com</code>,
    and <code>www.bar.com</code> was a separate IP interface, such
    that non-<code>Host:</code>-header-supporting browsers can use
    it, as before with Apache 1.0. If a request is made to
    <code>www.foo.com</code> and the request includes the header
    <code>Host: www.bar.com</code>, a page from
    <code>www.bar.com</code> will be sent. 

    <p>This is a security concern if you are controlling access to
    a particular server based on IP-layer controls, such as from
    within a firewall or router. Let's say <code>www.bar.com</code>
    in the above example was instead an intra-net server called
    <code>private.foo.com</code>, and the router used by foo.com
    only let internal users access <code>private.foo.com</code>.
    Obviously, <code>Host:</code> header functionality now allows
    someone who has access to <code>www.foo.com</code> to get
    <code>private.foo.com</code>, if they send a <code>Host:
    private.foo.com</code> header. It is important to note that
    this condition exists only if you only implement this policy at
    the IP layer - all security controls used by Apache
    (<em>i.e.</em>, <a href="../mod/mod_access.html">Allow, Deny
    from,</a> <em>etc.</em>) are consistently respected.</p>

    <h2>Compatibility with Older Browsers</h2>

    <p>As mentioned earlier, a majority of browsers do not send the
    required data for the new virtual hosts to work properly. These
    browsers will always be sent to the main server's pages. There
    is a workaround, albeit a slightly cumbersome one:</p>

    <p>To continue the <code>www.apache.org</code> example (Note:
    Apache's web server does not actually function in this manner),
    we might use the new <code>ServerPath</code> directive in the
    <code>www.apache.org</code> virtual host, for example:</p>
<pre>
    ServerPath /apache
</pre>

    <p>What does this mean? It means that a request for any file
    beginning with "<code>/apache</code>" will be looked for in the
    Apache docs. This means that the pages can be accessed as
    <code>http://www.apache.org/apache/</code> for all browsers,
    although new browsers can also access it as
    <code>http://www.apache.org/</code>.</p>

    <p>In order to make this work, put a link on your main server's
    page to <code>http://www.apache.org/apache/</code> (Note: Do
    not use <code>http://www.apache.org/</code> - this would create
    an endless loop). Then, in the virtual host's pages, be sure to
    use either purely relative links (<em>e.g.</em>,
    "<code>file.html</code>" or "<code>../icons/image.gif</code>"
    or links containing the prefacing <code>/apache/</code>
    (<em>e.g.</em>,
    "<code>http://www.apache.org/apache/file.html</code>" or
    "<code>/apache/docs/1.1/index.html</code>").</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. When a new browser
    contacts <code>http://www.apache.org/</code>, they will be
    directly taken to the Apache pages. Older browsers will be able
    to click on the link from the main server, go to
    <code>http://www.apache.org/apache/</code>, and then access the
    pages.</p>
    <!--#include virtual="footer.html" -->
  </body>
</html>