In the previous pages we have seen a few examples of how bindings are used to route requests to one of the installed websites. We will now summarize the observations we made earlier.
Each binding has 4 parameters:
- a protocol,
- an IP address,
- a host name
- and a port.
For our purposes the protocol is always HTTP so we will not mention the protocol further and only consider the 3 parameters: protocol, IP address and host name.
In a binding the wildcard * can be used for the IP address, the host name or both. A wildcard doesn't make sense for the port because it wouldn't possible for a webserver to listen to every port on the computer. Bindings that use a wildcard have the least precedence, they will only be used if no other binding matched the IP address and/or host name of the request.
When defining bindings there can be no ambiguity so the following constraints apply:
- Two bindings can't have the same values for all 3 parameters.
- Amongst all the bindings that use the same port, two bindings can't have the same values for the IP address and host name.
In the above rules the wildcard can just be considered a value like any other value so the same constraints apply.
The constraints only apply to those websites that are running. So for instance if you have 2 websites that have the same values for all 3 parameters it means only one of them can be running at any point in time else they'd violate the first constraint.
Here is the procedure that can be followed to know to which website a request will be routed.
First the port must be ones of the ports IIS is listening to. IIS only listens to the ports that appear once or more in bindings. There are therefore only 2 options:
- There is no binding for the port to which the request is sent and the request fails immediately. As mentioned earlier it's not possible to have a wildcard for the port and if there is no binding for the port IIS simply is not listening to it so there is no way this request can be handled in any way by IIS. On figure 1 this means the answer to the check T1 is No.
- There is one or more bindings for the port. Only those bindings that use that port are now considered. The other bindings can't be used since they are not for this port. There is no redirection mechanism possible as part of the bindings. If you want to redirect requests then that has to be done by some other mechanisms. On figure 1 this means the answer to the check T1 is Yes.
Assuming the port of the request was valid we now have a series of one or more bindings to consider and we need to use the IP address and host name to decided which one should be used. The follow procedure is used.
- If there is a binding that explicitly specifies both the IP address and the host name and they match the ones used in the request then that binding is used (check T2 on figure 1 is Yes). If not we go to step 2.
- If there is a binding that explicitly specifies the IP address used by the request and has a wildcard for the host name that binding is used (check T3 on figure 1 is Yes). If not we go to step 3.
- If we reach this step it means that there was no match amongst the bindings that explicitly specify an IP address. That means we need
to consider the bindings that use the wildcard for the IP address, if any. So the following steps apply.
- If there is a binding with a wildcard for the IP address but specifies a host name and it matches the one of the request then that binding is used (check T4 on figure 1 is Yes) else we go to step 3.
- If there is a binding with a wildcard for both the IP address and the host name that binding is used (check T5 on figure 1 is Yes). If not the request fails.
|Figure 1: Procedure to route a request|
blog comments powered by Disqus