Bindings: Did you say “Bindings?”
So you’ve been tasked with development of a new Web application to be hosted on IIS (any version)? The first thing on your mind is usually the design of the Website, how the application will interact with the middle-tier, and usually security. This is a great start in the design process. However, let’s not forget that often jumping into this level of design will mean that later on your going to make some other decisions a bit more tricky.
It starts with these questions:
- Am I going to host everything in one IIS Website?
- Will I use an “existing” Website like the Default Web Site or create my own?
- Will some of the site require secure authentication using SSL?
The first thing that often happens with developers posed with these questions are they say these aren’t important but I quickly smile and say, “We’ll see”.
The primary reason that these questions are important are around the fact Websites are accessed by every client using bindings. The end-user of your Web application(s) don’t know they are using bindings because they are usually hidden behind a nice, pretty “Web address” using DNS. If you don’t have the answer of how many Websites your Web application will utilize then you are going to be struggling when you are upset that you are limited to “rules” governed by directories.
You see, Websites have something called Server Bindings which represent the underlying address, port, and potentially a host header that your Website is accessed using. Do you think that HR staff would be happy if their Website is accessed using the same bindings as your company’s intranet? I would venture to guess the answer is no.
Bindings 101:
A typical binding for Websites are in the form of IP:Port:HostHeader. For all versions of IIS that anyone reading this in 2010 care about (version 6.0 and higher), the default Web Site binding is set to *:80:* meaning that all requests to that server will land at that site.
Valid Bindings:
| IP Field | Port Field | Host Header | Result |
| * | 80 | * | All requests to this server’s IP address will access this site. |
| * | 81 | * | All requests to this server’s IP address with :81 will access this site |
| 192.168.1.1. | 80 | * | All requests to this server’s IP address will access this site* |
| * | 80 | www.microsoft.com | All requests to this URL will access this site |
| * | 80 | microsoft.com | All requests to this URL will access this site |
For option where you utilize IP address as the “unique” point for access, you will need to disable HTTP.sys default behavior of listening on all IP addresses configured on your server. For example, if you have 192.168.1.1 and 192.167.1.2 configured as IP addresses on the same server the default behavior “out of the box” is to listen on port 80 no matter if you do the binding in the IIS Manager.
To change this behavior, you will need to configure HTTP.sys’s IPListenList to only listen on a specific address. This is done via the registry or NetSH depending on what you are most comfortable with.
Figure 1: Default setting for IPListen (blank equals *:80:*)
In short, if you plan to utilize a Website then know what your bindings will be and where your application will live in production. If a shared server, you can bet you will need a Host Header or a unique IP address so think ahead and get ‘er going.
Websites versus Application Pools
There are so many reasons that Websites & Application Pools are confused that I don’t have enough time to do a post on it. I’m not going to try and solve the debate here, but instead, I’m going to try and educate you on what the fundamental difference between the two are. In discussions with IT Pro’s & Developers, rarely will you have any of them “admit” they know what each is and when to utilize one or the other but my guess is that over 70% of them don’t know.
Thus, I hope for readers out there who used their decision engine (nice plug, ay?) to find this reading will enjoy learning this topic and we can together reduce this 70% to a much lower number…
Websites: Container of physical and virtual directories
It really is simple. A website is nothing more than a container of physical and virtual directories that have a unique “Server Binding” for clients to access the content. The default container in IIS, for years, has been %systemdrive%\inetpub\wwwroot unless you are doing a unattended install in IIS 6.0 which allowed you to put the files where ever you choose.
Path + Server Binding = Website … It really is easy.
NOTE: Their is a serious obmission completely on purpose here. As you can see, Websites have nothing to do with memory, server processes, bitness, or performance. They simply are a path + binding.
When to choose a “Website”
With that understanding, you can now make an educated guess as to how to answer the question of whether you should create a new Website or use an existing one. However, I will make sure to share it in case you missed it - “You decide whether to create a new Website based on whether you would like to have a unique binding for your Website or if you want to use an existing one.”
The path isn’t important in this equation as I can create a 1000 Websites all pointing to exactly the same path and there is absolutely no problems with doing this (of course, why in the heck would you do this is a great question). The key decision here is that any physical or virtual directory will always use the bindings of the Website so ensure that you understand this.
When to choose directories?
If there is a website which is already running and utilizing a binding that you would prefer to use then you should select this option. This allows you to utilize the resources of the parent site, if interested, as the server (e.g. IIS) will handle any requests over the same connection(s). For example, any physical or virtual directory in the IIS path is still considered “/” to the server as it builds out the URI because the bindings are already mapped at the site level. This means that URLs can be re-written to go various different places within the folder hiearchy over the the same connection since the binding is the “same”…
If you choose to put your Web application in its own Website then you will have to use the HTTP 302 redirection capability (exposed via Server.Transfer or other methods) to push the request elsewhere.
So, as you can see, thinking ahead of time about whether you are building a Website for your application or whether it is a child directory (physical or virtual) is an important piece of information to have locked early, early on!
Application Pools: Container of applications
The very nature of application pools is to do the obvious, contain a single or multiple applications. The introduction of application pools in IIS 6.0 caused some head scratching but in today’s world where IIS 6.0 is very engrain in enterprises and the Web leads to less scratching. However, again, development teams often make mistakes by not “thinking” about application pools and there impact on their new applications they are building. Hence the reason we will chat about this some more today…
First Concept… Windows Process = Application Pools *not* Windows Process = Website
Second Concept… Process Management = Application Pools *not* Process Management = Website
When to create a new Application?
By default, IIS 6.0 or IIS 7.0 must have a single application to run. If the root application (/) is deleted or corrupted then IIS will fail, as in, not serve your application. Both products ship with a default application which is assigned to the Default App Pool. I should not this is only if no other Microsoft features have been installed and instead we have the basic Web server installed.
As you can see, there is also a Classic .NET AppPool but no applications are currently bound to it. In IIS 7.0, any managed code application can choose to utilize the
Integrated Pipeline
or to use the classic
ASP.NET pipeline
which is present in IIS 6.0.
By default, you as a developer of a Web application can choose to simply inherit the settings of the parent Application Pool (/) and choose to not create your own. This is absolutely fine. So you might ask, what do I get from choosing this route? I’m glad you asked because it is important to know that you get all the settings of the parent application pool which in this case is the DefaultAppPool.
These settings include the following:
| Setting | Purpose |
| Recycling Settings | How often the App will be recycled such as by time intervals, memory usage, etc. |
| Process Security | Who is the identity that the W3WP process will run as |
| Pipeline Type (IIS 7.0 Only) | Whether to use the integrated pipeline, classic pipeline, or no Managed code at all |
| Bitness | Whether the process runs in native 64-bit or uses a 32-process (64-bit OS only) |
As you can see, you need make some important decisions early on or you are going to change a lot during the development process.
When to create a new Application Pool?
Well, it sounds like I’m best to create a new application pool for all my Web applications. I would say you’ve been suckered and convince that this is the best without all the facts. The fact is that creating an application pool includes understanding better your strategies for security such as do you run Network Service, a Domain Service Account, etc. that starts to complicate things very quickly. The one thing that many manage code developers often love to take advantage of is the caching capabilities of processes and manage code. Each time you create a application, bind it to its own unique application pool then you are limiting your ability to share cache with other .NET applications running on the same box. For example, if you have the Microsoft Enterprise Library in use all throughout your Web applications then you can often utilize caching to improve performance. As soon as you break these out into different process boundaries (e.g. App Pools) then you no longer have that benefit.
There are a number of these types of examples listed above that drives the question – Do I use my own application pool or do use another one already running? I’m happy to get posed a question via comments or email regarding this topic and see what your situation is and make my suggestion :)
Nonetheless, be careful in your planning when utilizing your own Application Pools and share resources where possible is my guidance. There are absolutely situations where one might choose to always go hard line with creation of app pools for every new Web development project. I just caution you and say, “Not so fast my friend… “
