The benefit of using host names in bindings becomes obvious when we have more than one website. Before proceeding with the examples in this section we restore the bindings for the default website to the original settings as they were shown in figure 2 on page 4.
The first step is to create a new directory that will be used to store the contents of the new website in the same way C:\inetpub\wwwroot does for the default website. We create the directory C:\inetpub\website1 and put a single index.html file in it as shown on figure 1.
|Figure 1: Directory for Website1|
And the contents of index.html are as follow:File: index.html
<html> <head><title>Welcome</title></head> <body> <p>website1</p> </body> </html>
We now right-click on the "Site" item in the "Connections" column of the IIS Manager. This brings up the contextual menu shown in figure 2.
|Figure 2: Adding a website|
Selecting the "Add Website..." item brings up the dialog shown in figure 3.
|Figure 3: Dialog to add a website|
We have filled it in with the details of our new website: website1. However we have left the host name blank for now to show what happens if we try to add it like this. If we press OK we get the following warning.
|Figure 4: Popup warning of a conflict between bindings|
The dialog is self-explanatory. With these bindings if both sites were running at the same time the route for a request would be ambiguous and IIS of course doesn't allow that. However it allows you to proceed with the binding if you want but only one of the sites will be allowed to be running at a time.
In our case this is not what we want though so we press "No" and update the settings to require the host name to be "website1" as shown on figure 5.
|Figure 5: Dialog to add a website|
This works fine now even if both sites are running at the same time. You could think there still is a conflict since the default website is ready to accept any host name in the request but bindings that explicitly specify a host name take precedence over the ones that do not. So the binding of the default website will only be taken into account if the host name specified in the request is not specified explicitly in a binding. We cover these rules in more details in the next section.
The IIS Manager now lists our new website as shown in figure 6.
|Figure 6: IIS Manager with the new website|
If we do
curl localhost we get the index.html file of the default website. If we do
curl website1 we
get the index.html file of website1. This is shown in figure 7.
|Figure 7: curl localhost and website1|
|The changes in the configuration file related to adding a website are covered in this IIS Configuration Files tutorial.|
So far we have used a port or a host name to route requests. The last parameter one can use to determine the destination of a request is the IP address.
For this tutorial we assume the computer has 2 IP addresses: 192.168.28.131 and 192.168.28.132. Note that it is possible to actually distinguish based on the loopback address, 127.0.0.1, but that's rather weird so we won't show that as an example.
We are now adding another website: website2. We follow similar steps as the ones we used to add website1. We add a directory c:\inetpub\website2 with an index.html file. We change the contents of that index.html file to mention "website2" in the body so that we can identify it when we get the files using cUrl. We complete the "Add Website" dialog as shown in figure 8.
|Figure 8: Dialog to add a website|
We now have two websites with bindings to "any" IP address and one website explictly bound to 192.168.28.132. This works the same way the host name works in the sense that if * is used for the IP address it means any IP address not explicitly used by other bindings. Since 192.168.28.132 is used by website2, it means that the remaining IP addresses are 192.168.28.131 and 127.0.0.1 and website1 and the default website will use those. The IIS Manager shows our current setup as shown in figure 9.
|Figure 9: IIS Manager showing the binding for our 3 websites|
This setup works fine because there is no ambiguity when routing the request. If the request destination is 192.168.28.132 then it must be for website2. If the request destination is 127.0.0.1 or 192.168.28.131 then the host name is used to decide whether it should go to the default website or website1 as was explained in the previous section.
Let's do a few cUrl requests to shown that it is indeed working like we expect (see figure 10).
|Figure 10: curl localhost, website1 and website2|
There is one last test to do to confirm how the bindings work. Instead of having a blank host name for the Website2 binding let's require it to be website2 as shown in figure 11.
|Figure 11: New binding for Website2|
So what is going to happen if we try to do
curl 192.168.28.132? This request doesn't contain a host name and the new binding
for website2 does require the "website2" host name so the request can't be sent to Website2. And there is no other binding for 192.168.28.132
that could handle the request. But the requets will not fail it will actually be sent to the default website because it has a rule that matches any IP address
and any host name. This means that the IP address and host name must always be considered together when figuring out how a request will be routed.
The execution of
curl 192.168.28.132 is shown in figure 12.
|Figure 12: curl 192.168.28.132|
blog comments powered by Disqus