IIS has the ability to host multiple websites on one single server. To do this, a unique combination of the host header name, IP address and port number must exist. This article will explain what a “host header” is, how it works, and explain some common misunderstandings of the host header concept.
The client and webserver communicates using the HTTP protocol. The data sent between the client and server is called a HTTP message (see RFC 2616, section 4). The HTTP message has a body section and a header section. The body section may contain the HTML code of the webpage returned from the server to the client as an answer to a GET request. The header section contains information such as Content-Length, Referer, Host (and possibly also much more).
To understand where the HTTP message is examined, it is crucial to understand the communication between the client and server. The communication is (typically) introduced by a user typing the domain name and port number into their browser (Internet Explorer). For example, say that the user want to visit http://www.ilopia.com, in this case the user would type the URL http://www.ilopia.com into their browser. Internet Explorer will default to the HTTP protocol and the default port (80) for HTTP.
The browser will now need to resolve the domain name the user has typed into their browser because the client must establish a connection to the IP address and port number. The resolution of the domain name into an IP address can be done by utilizing a DNS server or the hosts file.
Once the domain name has been resolved, the client established a connection to the webserver and then sends a request message. This request message contains the host header, and may look like:
GET /index.htm HTTP/1.1
The server receives the HTTP message and examines it. If a host header is found (a HTTP message may not have a host header), IIS will find out if there is any host header name configured in IIS that matches the host header received in the HTTP message. If there is a host header name that matches the host header, index.htm will be served from this website’s home folder.
The last step is that IIS will respond to the request.
As could be seen in the section “How the client communicates with the webserver” above, the HTTP message (and the host header) is not examined until a connection is established between the webserver and client. So when configuring IIS to use host headers, it is necessary to configure name resolution as well. Name resolution is not part of IIS (IIS is a web server, not a name resolution service). Instead a DNS service is necessary, or for a small network the hosts file may be sufficient.
Each website set up in IIS “binds” to an IP address, port number and host header name. Each website’s configuration is stored in the metabase property ServerBindings, which has the string format IP:Port:Hostname. An example would look like 192.168.0.1:80:www.gafvert.info. The host header name (www.gafvert.info in the example) and IP (192.168.0.1 in the example) can be omitted.
To determine which website should handle a request, IIS checks if there is a website configured to listen on the IP address and port number the request came in on, and which also matches the host header value sent in the HTTP message. If it finds a website with a ServerBindings property that matches this exactly, the request is routed to that website.
If there is no website with an exact match, IIS checks if there is a website configured to listen on all IP addresses (in IIS Manager called “All Unassigned”), the port the request came in on, and with a configured host header name matching what is sent in the HTTP message. If a match is found, IIS routes the request to that website.
The last step is to see if there is any website with a blank host header configured in IIS, which will then handle the request.
Using Host Headers to host multiple websites on IIS 6.0
Test host header configuration with the hosts file
Host Headers versus multiple IPs when hosting several websites
Can I use host headers to run multiple FTP sites?
Append a host header to a website in IIS by code
Working with .Net applications deployed on IIS now, I decided to refresh memories about IIS architecture. It can be helpful to any .NET developer.
IIS 7 and above have a similar HTTP request-processing flow as IIS 6.
Here is the diagram, with steps explanation below it.
In a worker process, an HTTP request passes through several ordered steps, called events, in the Web Server Core. At each event, a native module processes part of the request, such as authenticating the user or adding information to the event log. If a request requires a managed module, the native ManagedEngine module creates an AppDomain, where the managed module can perform the necessary processing, such as authenticating a user with Forms authentication. When the request passes through all of the events in the Web Server Core, the response is returned to HTTP.sys.
Diagram 2, below, shows an HTTP request entering the worker process.
It’s just a small piece of IIS architecture.For more information about IIS go to Introduction to IIS