Name based virtual hosting

What is virtual hosting?

When web sites, and therefore web servers, were first developed it was usual to devote an entire physical machine to serving a single site. As the World Wide Web matured, and more web sites needed hosting, this became a serious limitation.

To reduce the number of physical machines required administrators often installed multiple web server instances on a single machine. This solved the problem of requiring multiple servers to host multiple sites but it created a new problem that each server instance consumed considerable system resources.

The next advance in web server consolidation came with the advent of virtual hosting. In its first incarnation every web site was assigned an individual IP address and the web server was configured to listen on each address serving content from a different location on disk. This worked very well for many years however, as the IPv4 address space started to become exhausted, this technique soon started to suffer from the one address per site limitation imposed by the original HTTP protocol.

The IETF soon realised that this limitation of the HTTP protocol needed to be addressed. An updated version of the HTTP protocol was soon released which, among many other improvements, addressed this issue by adding a new header to the request section of the protocol specifying the host being queried. This allowed many web sites to be hosted on a single IP address with the web server deciding which site to serve based on the content of the host header. This technique rapidly became known as name-based virtual-hosting, for fairly obvious reasons, causing the previous technique to become known as address-based virtual-hosting.

Why is there a default virtual host?

When the revised HTTP protocol was first implemented a great many web sites were already deployed and those web sites were being accessed by a variety of user agents. Clearly this required that the new HTTP protocol was backward-compatible with the existing user agents so that they could be updated and the new HTTP protocol also had to be forward-compatible so that any new user agent would be capable of communicating with an old server.

There is another serious limitation with name based virtual hosting. The HTTPS protocol, which is used to communicate with SSL secured web sites, cannot be extended with a host header as the SSL certificate is sent to the user-agent and encryption negotiated before any headers are exchanged. This means that name based virtual hosting cannot be used to host more than a single SSL secured site on a single IP address as the server has no way to know in advance which SSL certificate should be used. Address based virtual hosting can, of course, still be used to host more than one SSL secured site on a single server instance.

The default virtual host will therefore be served to any user agents which do not specify a host when issuing the HTTP request. The default virtual host will be also be served to anySSL requests issued which resolve to the IP address on which name based virtual hosting is being used.

Warning:
If a request for an SSL secured site other than that which is designated as the default SSL virtual-host is made to an address which is configured for name-based virtual-hosting all modern user-agents will flag an SSL certificate validation problem. For this reason great care must be taken when configuring name resolution for such sites to ensure that all such requests be issued to the correct address.
 

Reconfiguring the default virtual host

If the server on which Apache has been installed has only a single IP address then the default configuration, which instructs the daemon to listen on all addresses and use all of those addresses for name-based virtual-hosts, can be left as is. If the server has more than a single IP address then it makes sense to only use one for name-based virtual-hosting thus leaving the others free for use by address-based virtual-hosts and, more commonly, SSL secured sites.

The modifications to the /etc/apache2/vhosts.d/00_default_vhost.conf which are required to enable name-based virtual hosting on a single IP address are shown below. As you can see in the example we are using 10.0.1.80 as our network address. You will need to change this to reflect the IP address range assigned to your server.

/etc/apache2/vhosts.d/00_default_vhost.conf
Listen 80

NameVirtualHost *:80
NameVirtualHost 10.0.1.80:80

<VirtualHost *:80>
<VirtualHost 10.0.1.80:80>
Caution:
There can be multiple NameVirtualHost declarations. If more than one such declaration appears then "groups" of name-based virtual-hosts are created, each with its own IP address and thus each requiring its own default virtual-host. Care should therefore be taken to always ensure a corresponding default <VirtualHost> section exists for each such group.
 

Configuring a new name-based virtual host

To create a new name-based virtual-host we simply need to create a single configuration file, an example of which is shown below, and place it in the /etc/apache2/vhosts.d directory.

/etc/apache2/vhosts.d/10_hacking_vhost.conf
<VirtualHost *:80>
ServerName www.hacking.co.uk
ServerAlias hacking.co.uk hacking.internal.hacking.co.uk hacking

DocumentRoot "/var/www/hacking/website"

<Directory "/var/www/hacking/website">
Options Indexes

Order allow,deny
Allow from all
</Directory>
</VirtualHost>
Caution:
If you modified the configuration of the Apache daemon to run name-based virtual-hosts on only a single IP address, as described above, you will need to replace the * in the <VirtualHost *:80> entry with the IP address you used when configuring the NameVirtualHost declaration for the appropriate name-based virtual-host group.
 

As you can see the configuration required is fairly minimal. The first line specifies that this is a declaration of a virtual-host. It also specifies which NameVirtualHost group this virtual-host should be associated with.

The ServerName specifies the official name of the web site and should ideally correspond to the fully qualified host name of the site to be served. The next line contains a ServerAlias entry which specifies any other aliases that this virtual-host might be addressed using. As you can see in our example we have specified the unqualified domain name, in our case hacking.co.uk, so that any requests to our unqualified domain will also be served. We have also added two further aliases which are used by our development team to access the test version of the site allowing us to reuse the configuration files unchanged in both production and development environments.

The remainder of the configuration consists of the DocumentRoot directive and a Directory block. As these are identical to those which were discussed in the previous section we shall not go over them again here.

Once the configuration is complete the apache daemon can be signalled to reload its configuration files using the command shown below.

lisa /etc/init.d/apache2 reload