IIS, host headers and the IIS screen of confusion
If you ever use hosts file re-directs and multiple sites hosted on the same IIS server, you may at one point have teared your hair out when you see the IIS logo screen rather than the site you expect. You might think everything is setup correctly and then go and play with loads of stuff until it eventually works.
The reason is fortunately quite straight-forward but not always obvious so here we go:
Firstly, when you host a site in IIS, you can either host it under the default web site or you can host it under its own site. Of course you can't have more than one site occupying the same place otherwise when you type in http://www.myserver.com/ how would the system know what site to return? Generally, the default web site is located at the root of the web server and any sites underneath are reached by using their directory name (and therefore the index.html/html or default.aspx that lives in that directory) such as http://www.myserver.com/somesiteunderdefault/. Many times, however, we would consider this messy and unprofessional and would want each site to have its own url such as www.myserver.com and www.myothersite.com both pointing to the same web server. If we do this without setting up IIS, all that would happen is they would both hit the default web site. In order to make them hit different sites, we have to set up bindings.
To set up a binding, we click on the web site in question and (in IIS7) click on Bindings on the right-hand side. This allows up to setup multiple bindings. A binding is simply a protocol (http or https), a URL and an optional port number (80 being the default). So on one of our sites we say that when a request comes in for www.myserver.com, we want this site to be served back to the user. We repeat the process for our second site, setting up a binding to www.myothersite.com and we're good to go. What happens now is that when we request a site from the web server, the server will first check any bindings and match these to the Host Header, port, protocol passed in from the client (in other words, what is the url that was typed in to request this site) and if a match is found, it is passed to the relevant site to handle. If no match is found and there is no site in the default web site area (as is the case by default), you get the IIS splash graphic.
One of the confusing things is when using urls that are set in your hosts file, rather than set in your system/internet DNS, you have to be really careful since IIS is looking for the url you typed in. For instance, if rather than typing in www.myserver.com, you typed in either an ipaddress that pointed to the same machine or perhaps another url that has no binding set up, IIS will not match it and you will get the IIS screen again.
If this all gets a bit much for you, an easy way to find out what is going on is to install Fiddler and request the site from your browser, see what URL is looked up and then ping that server to check it is accessing the correct IP address for the web server, then double-check that the binding for that web site is correct in IIS. Be extra careful of additional sites that might be used invisibly to the user (although they will appear in Fiddler) and ensure they also have host entries pointing to the correct place and if relevant bindings in IIS.
The reason is fortunately quite straight-forward but not always obvious so here we go:
Firstly, when you host a site in IIS, you can either host it under the default web site or you can host it under its own site. Of course you can't have more than one site occupying the same place otherwise when you type in http://www.myserver.com/ how would the system know what site to return? Generally, the default web site is located at the root of the web server and any sites underneath are reached by using their directory name (and therefore the index.html/html or default.aspx that lives in that directory) such as http://www.myserver.com/somesiteunderdefault/. Many times, however, we would consider this messy and unprofessional and would want each site to have its own url such as www.myserver.com and www.myothersite.com both pointing to the same web server. If we do this without setting up IIS, all that would happen is they would both hit the default web site. In order to make them hit different sites, we have to set up bindings.
To set up a binding, we click on the web site in question and (in IIS7) click on Bindings on the right-hand side. This allows up to setup multiple bindings. A binding is simply a protocol (http or https), a URL and an optional port number (80 being the default). So on one of our sites we say that when a request comes in for www.myserver.com, we want this site to be served back to the user. We repeat the process for our second site, setting up a binding to www.myothersite.com and we're good to go. What happens now is that when we request a site from the web server, the server will first check any bindings and match these to the Host Header, port, protocol passed in from the client (in other words, what is the url that was typed in to request this site) and if a match is found, it is passed to the relevant site to handle. If no match is found and there is no site in the default web site area (as is the case by default), you get the IIS splash graphic.
One of the confusing things is when using urls that are set in your hosts file, rather than set in your system/internet DNS, you have to be really careful since IIS is looking for the url you typed in. For instance, if rather than typing in www.myserver.com, you typed in either an ipaddress that pointed to the same machine or perhaps another url that has no binding set up, IIS will not match it and you will get the IIS screen again.
If this all gets a bit much for you, an easy way to find out what is going on is to install Fiddler and request the site from your browser, see what URL is looked up and then ping that server to check it is accessing the correct IP address for the web server, then double-check that the binding for that web site is correct in IIS. Be extra careful of additional sites that might be used invisibly to the user (although they will appear in Fiddler) and ensure they also have host entries pointing to the correct place and if relevant bindings in IIS.