The term Virtual Hosts is used a great deal when setting up your Slice. Let's take a look at what Virtual Hosts are and why they are important.
It is also worth noting that the term Virtual Hosts is used with all web servers. Once you have the principle clear in your mind, it makes setting them up on any web server much easier.
Let's take a quick look at what happens when you type a web address into your browser.
This is not a technical document so forgive the simplicity but the basics are quite simple:
Your browser sends an HTTP request to your ISP.
The request is routed, via your ISP and other servers, to where the IP address is located (i.e. your Slice).
The Slice web server processes the HTTP request and returns the HTML representation of the request to your browser.
Your browser interprets the HTML representation and parses the page for you.
You click 'next' and the whole process is repeated.
Single IP address
In this simple outline there is an important issue to note in that the web address you type into the browser is turned into an IP address.
So, for example, www.bbc.co.uk is turned into 188.8.131.52 (try it, put both into your browser, they both display the same thing).
We use names as humans are pretty bad at remembering numbers.
I've only got 1 IP address
So if my Slice only has one IP address can I only host one domain?
Nope. This is where virtual hosts come in...
You can allocated many domains to one IP address.
So lets say you have three domains: domain1.com, domain2.com and domain3.com and all of them have been configured to point to your Slice's IP address.
Using exactly the same (simplified) routing shown above, when any of your 3 domains are entered into a browser, the requests end up at your Slice.
Enter the Web Server. It doesn't really matter what Web Server we are talking about here, it could be Apache, Litespeed, Nginx, lighttpd or any of the dozens of Web Servers available.
The point is that the request for 3 different domains has arrived at a single point: Your Slice and your Web Server.
You see Web Servers are quite cool.
They are able to look at those requests and say "Hey, this guy wants an HTML representation of domain1.com and look, this guy wants one of domain2.com".
The server knows which file to parse and what to send back to the browser because you defined different settings and file locations for each domain in your Virtual Hosts file.
Each web server differs slightly in how to set up the Virtual Hosts file but they all have the same base settings:
Virtual Host Name: The name of the domain being requested - e.g. domain3.com.
Domain Directory: The location of the files for the requested domain.
Is that it?
Of course, there are loads of settings you can customise for each Virtual Host but the basics remain the same: Receive a request for a domain, located the requested domain's directory and, depending on what was requested, serve the requested files.
What if I enter the IP address?
Ah. Now you've hit on the weak spot of name based Virtual Hosts: If all the domains have the same IP address, what happens when I enter the IP address?
There is usually a 'default' domain. You may not have expressly set it up that way, but if the IP address is entered it is 'usual' for the first domain (alphabetically) to be served.
As an example, in the Debian Etch Apache install, the default Virtual Host is named '000-default'. So if you have not expressly defined a Virtual Host for the IP address, then 000-default will be used.
It is worth saying that different web servers do act differently here. The main point is that, in this example, there is only one IP address so only one domain can be served.
However, it is relatively rare for people to browse around using IP addresses. Take this site, did you enter the IP address or the domain name?
As I said, this is not a technical document (in case you didn't notice!) but the intention was to introduce the principles of Virtual Hosts.
I recommend reading the Multiple Hosts Layout article next. It outlines the Virtual Host directory structure and file locations used throughout these articles.