David Russell

Sometimes I run across things I should have known a long time ago. Sometimes, when I find those things, I say to myself, “Man, I should have figured that out. It makes so much sense.”

Virtual hosts are one such thing.

A few weeks ago I was stumbling around the Godbit forums as I do at least once a day and I was intrigued by a post about virtual hosts. I was a bit misled, thinking the topic was a web host offering service delivered on a virtual machine (more on that later.) Instead, the post revolved around the idea of creating a set of locally resolving URLs for use in the test environment so that projects can be delivered in more of a ‘root’ location.

Allow me to explain a little further.

In a local test environment, a web server combined with a scripting language (or two) and even databases can produce the same kind of results that you would receive while working on a traditional web server, perhaps just like the one at your hosting company. So for all my projects, I create a folder that is ‘served’ to my own machine. The HTML documents and PHP scripts I produce can be examined and run in place allowing me to test and tweak these files very quickly and without the need to transfer files back and forth between a remote server. Of course, once a project is complete I do make exchanges between the remote server and push the content live on the w3.

But before those files ever see the light of day, they live for quite some time on my local server. When I load a project, I usually just throw the standard local machine URL and the project folder to view my work:

http://localhost/project

Now, this works quite well most of the time, but occasionally I’ve run into some small snags because the information is delivered from a subfolder. .htaccess files typically struggle a bit here. It would be best if we could run things from a root folder, but it’s certainly not ideal to run multiple projects from that root folder. It’d be impossible to manage.

Enter virtual hosts.

By editing some information in the hosts file of my machine and editing the conf file in the Apache web server, I can create any URL I want and associate that URL with any folder or subfolder of the webserver’s /htdocs directory (the directory responsible for storing the web content that is served.) So, theoretically I can create a URL for that same project that reads more like a standard URL. In fact, it can even be:

http://www.davidproject1.com/

Yep. Even though I don’t own that domain, and would never want to anyway, I can tie that URL to the project folder and have that information served from my local server into my browser of choice.

The first trick is editing the Windows hosts file. Grab your favorite plain text editor and point your file browser to C:/WINDOWS/system32/drivers/etc/. Once there, open the hosts file. (You can select Notepad from the list of available apps if you don’t care to grab something better to edit with.) Your file will open to something like this:

# Copyright (c) 1993-1999 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

127.0.0.1       localhost

The first several lines of the file (the lines that begin with a hash mark) are just commentary for the file. The line with no hash in front is where the real action begins. 127.0.0.1 is the loopback¹ address of your machine (not to be confused with the local area network IP or public IP addresses which are both different.) localhost is simply the domain that resolves to the loopback address of 127.0.0.1. Essentially, the loopback allows you “address” your own machine from your own machine. Yeah, cool. You can probably start to see where we are going with this. Below that last line, go ahead and add a line like this:

127.0.0.1       myspace.com

Now save the file. You can leave the hosts file open in your text editor for now.

Oh boy. This is going to be fun. Now pull up a browser and enter myspace.com into the address bar and go.

Sweet! No more MySpace. Now, the myspace.com domain just resolves to your own machine because your hosts file is saying “all requests to myspace.com should resolve locally, not via the Internet.” Woo hoo. You can really have some fun with this! (But play nice!)

Seriously now, go back and change the hosts file, remove that myspace.com nonsense (you can’t live without it), and add in some domains that are easy to remember and are related to your projects. You can even create a new domain extension (TLD) if you like. For instance, my church related projects look something like this:

127.0.0.1       http://buzzconference.ncc

That way, I don’t confuse the .com or any other URL with my local project.

Make the system your own and feel free to use regular domains or even domains without extensions, like zulu-project which would resolve locally by browsing to http://zulu-project.

Until now, your domains only resolve to the root folder of your web server, just like http://localhost does. In the next step, we’ll let Apache know that we want certain local requests routed to a particular folder. If you’ve never edited Apache’s conf file, you may want to read up on a few docs at Apache. It’s really not as difficult as it seems, but you do want to exercise some caution as with anything like this.

You can find the httpd.conf file in the /conf directory of the Apache installation. Also, some versions of Apache actually list the virtual hosts information in a separate file called https-vhosts.conf. If yours is the latter, that’s where you’ll edit. For the rest of us, pop open that httpd.conf and scroll way down. It’s probably near the bottom. The line you’ll be looking for should read NameVirtualHost 127.0.0.1. If there is a hash sign (#) commenting out the line, just remove the hash to activate that line. Now for each and every local project or site that you’d like to run, add a set of lines like this:

<VirtualHost 127.0.0.1>
    ServerName localhost
    DocumentRoot "C:&#092Program Files&#092xampp&#092htdocs"
</VirtualHost>

In each case, replace localhost with the domain that you listed in the hosts file. Then, edit the DocumentRoot to the path of the folder that the project or site resides in. An example in my case might read like this:

<VirtualHost 127.0.0.1>
    ServerName buzzconference.ncc
    DocumentRoot "C:&#092Program Files&#092xampp&#092htdocs&#092buzzconference"
</VirtualHost>

To get Apache to recognize your new settings, you’ll need to restart the Apache server. In fact, any time you change the conf file, you should restart Apache as soon as it’s possible to do so.

Now when you load your project domain into your browser, the hosts file will keep your domain local and the Apache conf file will route your request to the appropriate folder.

Virtual Hosts! A must-have little hack in the tool belt of every web developer.

Apache Virtual Host Documentation

XAMPP - Install Apache, PHP, Perl and MySQL in one easy go.

Article on Virtual Hosts

The Godbit Discussion and Other Links

Virtual hosts are possible with IIS. I don’t use IIS. But there should be lots of information out there on it if you are interested.

¹Thanks to Pastor Sam for pointing out the proper semantics of the loopback address.

[tags]apache, web, server, virtual, host, domain, local, development[/tags]