![[APACHE DOCUMENTATION]](../images/sub.gif)
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 www.company1.com and
www.company2.com, without requiring the user to
know any extra path information.
Apache was one of the first servers to support virtual hosts
right out of the box, but since the base HTTP
(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) is available.
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 HTTP/1.1 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.
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.
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 httpd.conf or
srm.conf) code similar to the following:
<VirtualHost www.apache.org>
ServerName www.apache.org
DocumentRoot /usr/web/apache
</VirtualHost>
Of course, any additional directives can (and should) be
placed into the <VirtualHost> section. To
make this work, all that is needed is to make sure that the
www.apache.org DNS entry points to the same IP
address as the main server. Optionally, you could simply use
that IP address in the <VirtualHost> entry.
Additionally, many servers may wish to be accessible by more
than one name. For example, the Apache server might want to be
accessible as apache.org, or
ftp.apache.org, assuming the IP addresses pointed
to the same server. In fact, one might want it so that all
addresses at apache.org were picked up by the
server. This is possible with the ServerAlias
directive, placed inside the <VirtualHost> section. For
example:
ServerAlias apache.org *.apache.org
Note that you can use * and ? as
wild-card characters.
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 ServerAlias www
www.physics. 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.
Host: header through all IP interfaces, even those
which are configured to use different IP interfaces. For
example, if the configuration for www.foo.com
contained a virtual host section for www.bar.com,
and www.bar.com was a separate IP interface, such
that non-Host:-header-supporting browsers can use
it, as before with Apache 1.0. If a request is made to
www.foo.com and the request includes the header
Host: www.bar.com, a page from
www.bar.com will be sent.
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 www.bar.com
in the above example was instead an intra-net server called
private.foo.com, and the router used by foo.com
only let internal users access private.foo.com.
Obviously, Host: header functionality now allows
someone who has access to www.foo.com to get
private.foo.com, if they send a Host:
private.foo.com 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
(i.e., Allow, Deny
from, etc.) are consistently respected.
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:
To continue the www.apache.org example (Note:
Apache's web server does not actually function in this manner),
we might use the new ServerPath directive in the
www.apache.org virtual host, for example:
ServerPath /apache
What does this mean? It means that a request for any file
beginning with "/apache" will be looked for in the
Apache docs. This means that the pages can be accessed as
http://www.apache.org/apache/ for all browsers,
although new browsers can also access it as
http://www.apache.org/.
In order to make this work, put a link on your main server's
page to http://www.apache.org/apache/ (Note: Do
not use http://www.apache.org/ - this would create
an endless loop). Then, in the virtual host's pages, be sure to
use either purely relative links (e.g.,
"file.html" or "../icons/image.gif"
or links containing the prefacing /apache/
(e.g.,
"http://www.apache.org/apache/file.html" or
"/apache/docs/1.1/index.html").
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 http://www.apache.org/, 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
http://www.apache.org/apache/, and then access the
pages.
