This page by Cris Mooney, my home page is here. Edited Feb 22, 1999

This page is dedicated to Internet Information Server (IIS) 4 Host Headers (a new feature not available in IIS 3). When I wanted to use the Host Headers feature of IIS 4 I had a hell of a time, and found minimal help. Moreover, I had to get the IIS Resource Kit to finally figure things out. So, now that I have a clue, I put together this page as notes for me, and to help anyone else tht might be struggling.

I retain no copyright to this info, copy it and distribute it as you like without the need to credit me; likewise, use at your own risk. I think this is right, but I am not perfect. Please let me know if you find any errors in this page, via mail to csm@forus.com, and I will fix them within the day.

Host Headers is a feature of IIS 4 that allows you to specify multiple unique web sites using the same IP address. Support for Host Headers was not available in IIS 3, and when I tried to make the work properly in IIS 4 using the MS docs a couple gotchas messed with me. These notes are to help you get them working properly (I hope).

The Original Issue
Basic HTML browser client requests do not pass the first part of the URL, the host name. Thus "http://www.foo.com/index.html" is requested by contacting the machine (with IP denoted by "www.foo.com") as a call for "/index.hml" (www.foo.com, called the "host header" is lost). As a result, if you have "www.foo.com" and "www.bar.com" defined in DNS as the same IP address, then you have ambiguity. That is, "http://www.foo.com/index.hml" and "http://www.bar.com/index.html" would both come in to the machine as a request for "/index.html".

The First Level IIS 4 Host Headers Solution
The HTTP 1.1 protocol, supported by most modern browser clients, passes along the "host header" as a separate part of the request. Thus, if the server is smart, it can use this to resolve the ambiguity. IIS3 was not this smart, it ignores host headers, but IIS4 is. To use this in IIS4, you simply create two sites with the same IP address. However, in each of them you use the "Advanced" settings next to the IP address in the site properties to enter the unique "Host Headers". When IIS4 gets a request, it looks through all "Advanced" settings for all sites, and find the best (most detailed) match.

So, it is very simple to create multiple sites on the same IP using IIS4. Just be sure to fill in the advanced IP settings for each host.

Example of advanced settings, where the DNS for www.foo.com, foo.com, www.bar.com, and www.other.com all resolve to 128.1.1.1:
 Site1
  128.1.1.1     80     <left empty, no host header name here>
  128.1.1.1     80     www.foo.com
  128.1.1.1     80     foo.com
 Site2
  128.1.1.1     80     www.bar.com

In this example "http://www.foo.com" will go to site 1,  "http://www.bar.com" will go to site 2, and "http://www.other.com" will default to site 1 (default rule #1 is closest match).

NOTE: This configuration is done in the Microsoft Managment Console (MMC) with IIS 4 module, which should be in your Start menu under "Programs\ Windows NT 4 Option Pack\ Microsoft Internet Information Server" as "Internet Service Manager" (a shortcut to "C:\WINNT\system32\mmc.exe C:\WINNT\System32\inetsrv\iis.msc").

The New Problem (Old Browsers and stuff)
The simple solution gets most problems solved. And, to get up and running that is all you NEED to do. However, a problem arises if the browser does not support "host headers" (usually old browsers), or if the user attempts to go to "http://128.1.1.1".

How old are "old browsers" (who supports HTTP 1.1)?

I don't really know. I do know that Netscape 2.0.2 on Mac supports host headers (works OK). However, NCSA Mosaic 2.0.1 PPC for the Mac has problems. I think you have to go way back, I just don't know how far. If you have some old browsers, you might wish to point them at http://www.manynet.org. If the browse is old enough, you will not get to the page directly, instead getting a list of sites (the same list you see if you point your browser at http://206.210.79.19).

A site here, located courtesy Tim of the Musar Information Network, provides some stats collected in 1997.

Summary: point your browser(s) at http://www.manynet.org, if you get there directly then your browser is OK; if you see a list of sites, it has a problem.

Should you find some more information, please let me know at csm@forus.com so I can add it to this page.

Of course, old browsers are not the only issue; my solution also handles when someone types in the IP address directly (like http://206.210.79.19).

Live Solution Example
Everything below is a hypothetical example, created off the top of my head based on my implementation. For a real world working model, you can visit my sites at "206.210.79.19". Try "http://206.210.79.19", which hosts the sites "http://www.manynet.org", "http://www.sauereisen.com", "http://www.landgrove.com", and "http://www.paulbrokering.com" (an others by now). Also, try something complex like "http://206.210.79.19/contact.html" and then pick "www.sauereisen.com", and note that "Contact.html" does not get lost. This is all supported with scripts like the ones found at "ftp://ftp.forus.com/forus/csm/hostheaders/scripts/".

The Second Level Enhancements
Nothing changes from the first level, we just add some enhancements to handle old browsers and other unique issues. Microsoft describes a solution for old browsers which has IIS4 utilize Active Server Pages (ASP) based on registry entries. If you have the documents installed, you will find this solution at your site as "http://localhost/iishelp/iis/htm/core/iisuphh.htm" (I have made a local copy here in case your configuration is not complete or is messed up). Howeer, following Microsoft's directions did not work for me, and was not comprehensive. The basic solution is right, but there are some errors/omitions in the docs, and some extra things are not there, so this page supplements their solution.

Assuming you have one site "http://www.foo.com" and another "http://www.bar.com" defined as in the example above, do this:
  1. Create a "scripts" folder, or use the one in your INetPub folder (maybe "C:\INetPub\Scripts"), and put the scripts Cookie.asp, Munge.asp, and Redirect.asp in the folder. The scripts are detailed on the "http://localhost/iishelp/iis/htm/core/iisuphh.htm" (local copy here). You might use my enhanced versions, which you can find here "ftp://ftp.forus.com/forus/csm/hostheaders/scripts/", since they address other issues. Note the name of this virtual directory must be "Scripts", or else you must alter the values for DLCCookieMenuDocumentString, and DLCMungeMenuDocumentString below. Likewise, the files must be named "Cookie" & "Munge" or you must change the same registry items below, and you must name the other file "Redirect" or fix up the "Cookie" script (I have not tested other names, so I recommend sticking to the names given here).
  2. Create a "New-Virtual Directory" "Scripts" to the Scripts folder (in #1 above) using the IIS4 Microsoft Management Console (MMC) in at least on of your sites (to be used in DLCHostNameString). For example, in site "site 1", "www.foo.com".
  3. Create the registry items listed in "http://localhost/iishelp/iis/htm/core/iisuphh.htm" (local copy here). Note that these items need to be created as "values", not "keys" as in the document, and all should be of type "REG_SZ" except "DLCSupport", which should be of type "REG_WORD". Thus, in "HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet \ Services\ W3SVC\ Parameters" you should have registry entries like:
    4. Note: To add these items iuse the registry editor (regedt32.exe), select the "Parameters" item in the path above, and "Edit/Add Value" for each item, giving the appropriate DLC* name, and providing the value as above (without quotes). Don't forget, DLCSupport's unique REG_DWORD type!
  4. Shutdown and restart your IIS server, so the registry items take effect. I do this in the services control panel, by stopping IIS Admin Service, which lists other services it will also stop. Then I start the IIS Admin Service, and start the other services it listed that it also stopped. There may be a better way.
  5. OPTIONAL ADVANCED: Create a new "empty" site "default <IP>" (any name), that has only the simple IP address, with no host header. This is the same entry shown in the example above as "128.1.1.1     80     <left empty, no host header name here>", and you should remove that entry from any other sites that use your IP "128.1.1.1". In my example, you would remove the <left empty>" entry, then create this "default <IP>" site. This will catch any requests from "host header" enabled browsers, that do not have a specified host header in one of your sites. For example "http://128.1.1.1", or "http://www.other.com". Note, my solution here will keep the details of the full path of the URL. In this "default" site:
  6. FOR EACH SITE, AND EACH SITE YOU ADD IN THE FUTURE:
One Advanced Idea (left to you!)
This whole setup, basically outlined by Microsoft, adds an extra level of directory that you might be able to eliminate. I stuck with the original design to minimize modifications to Microsoft's directions. However, if you want to think, I believe that you can eliminate the "Scripts" directory, which would simplify maintenance (like what you have to do for each new site you add) and logic. This theory assumes that IIS does not have any dependency on this extra level of directories. To eliminate "Scripts" I think you would simply create your "HostMenu" folder anywhere you want (rather than just being the parent to "scripts"), and put the Cookie/Munge/Redirect ASP scripts in "HostMenu" instead of in the "Scripts" folder. Then change the DLCCookieMenuDocumentString (now "/Cookie.asp") and DLCMungeMenuDocumentString (now "/Munge.asp") to eliminate the "/Scripts", and fix up the path names in the Cookie/Munge/Redirect scripts as well as in "sitelist.html", and then you do not need the "scripts" virtual directory in every site. Hypothetically, you may already have some virtual folder in every site, and you could use this as your "HostMenu" folder, perhaps the one named "scripts" already (take that for confusing the issue!)

Summary
The docs for implementing Old Browsers using Host Headers in IIS 4 has some minor errors, and the solution is not comprehensive. I hope these notes offered the corrections required for the registry entry items, and the need to restart the IIS server, as well as the enhancements I added to cover the more obscure cases prove valuable to you. Note that some of my suggestions are to handle obscure cases; you might get away without doing as I have outlined, but some case might not be handled (likewise, there may be some case I have missed). Hopefully, if you follow the steps above your site will be accessible by everyone.

If you have problems, drop me a note with the URL of what you have set up and I will poke and see if I have any suggestions...after all I might have missed something!

Troubles?

Related links


Regards,
Cris Mooney
csm@forus.com
http://www.forus.com/csm