IIS Process ASP.NET Request

When request come from client to the server a lot of operation is performed before sending response to the client. This is all about how IIS Process the request.  Here I am not going to describe the Page Life Cycle and there events, this article is all about the operation of IIS Level.  Before we start with the actual details, let’s start from the beginning so that each and everyone understand it's details easily.  Please provide your valuable feedback and suggestion to improve this article.

What is Web Server ?

When we run our ASP.NET Web Application from visual studio IDE, VS Integrated ASP.NET Engine is responsible to execute all kind of asp.net requests and responses.  The process name is "WebDev.WebServer.Exe" which actually takw care of all request and response of an web application which is running from Visual Studio IDE.
Now, the name “Web Server” come into picture when we want to host the application on a centralized location and wanted to access from many locations. Web server is responsible for handle all the requests that are coming from clients, process them and provide the responses.

What is IIS ?

IIS (Internet Information Server) is one of the most powerful web servers from Microsoft that is used to host your ASP.NET Web application. IIS has it's own ASP.NET Process Engine  to handle the ASP.NET request. So, when a request comes from client to server, IIS takes that request and  process it and send response back to clients.

Request Processing :

Hope, till now it’s clear to you that what is Web server and IIS is and what is the use of them. Now let’s have a look how they do things internally. Before we move ahead, you have to know about two main concepts

1.    Worker Process
2.    Application Pool

Worker Process:  Worker Process (w3wp.exe) runs the ASP.Net application in IIS. This process is responsible to manage all the request and response that are coming from client system.  All the ASP.Net functionality runs under the scope of worker process.  When a request comes to the server from a client worker process is responsible to generate the request and response. In a single word we can say worker process is the heart of ASP.NET Web Application which runs on IIS.

Application Pool:  Application pool is the container of worker process.  Application pools is used to separate sets of IIS worker processes that share the same configuration.  Application pools enables a better security, reliability, and availability for any web application.  The worker process serves as the process boundary that separates each application pool so that when one worker process or application is having an issue or recycles, other applications or worker processes are not affected. This makes sure that a particular web application doesn't not impact other web application as they they are configured into different application pools.

Application Pool with multiple worker process is called “Web Garden”.

Now, I have covered all the basic stuff like Web server, Application Pool, Worker process. Now let’s have look how IIS process the request when a new request comes up from client.

If we look into the IIS 6.0 Architecture, we can divided them into Two Layer

1.    Kernel Mode
2.    User Mode

Now, Kernel mode is introduced with IIS 6.0, which contains the HTTP.SYS.  So whenever a request comes from Client to Server, it will hit HTTP.SYS First.

Now, HTTP.SYS is Responsible for pass the request to particular Application pool. Now here is one question, How HTTP.SYS comes to know where to send the request?  This is not a random pickup. Whenever we creates a new Application Pool, the ID of the Application Pool is being generated and it’s registered with the HTTP.SYS. So whenever HTTP.SYS Received the request from any web application, it checks for the Application Pool and based on the application pool it send the request.

So, this was the first steps of IIS Request Processing.

Till now, Client Requested for some information and request came to the Kernel level of IIS means at HTTP.SYS. HTTP.SYS has been identified the name of the application pool where to send. Now, let’s see how this request moves from HTTP.SYS to Application Pool.
In User Level of IIS, we have Web Admin Services (WAS) which takes the request from HTTP.SYS and pass it to the respective application pool.

When Application pool receive the request, it simply pass the request to worker process (w3wp.exe) . The worker process “w3wp.exe” looks up the URL of the request in order to load the correct ISAPI extension. ISAPI extensions are the IIS way to handle requests for different resources. Once ASP.NET is installed, it installs its own ISAPI extension (aspnet_isapi.dll) and adds the mapping into IIS.  

Note : Sometimes if we install IIS after installing asp.net, we need to register the extension with IIS using aspnet_regiis command.

When Worker process loads the aspnet_isapi.dll, it start an HTTPRuntime, which is the entry point of an application. HTTPRuntime is a class which calls the ProcessRequest method to start Processing.

When this methods called, a new instance of HTTPContext is been created.  Which is accessible using HTTPContext.Current  Properties. This object still remains alive during life time of object request.  Using HttpContext.Current we can access some other objects like Request, Response, Session etc.

After that HttpRuntime load an HttpApplication object with the help of  HttpApplicationFactory class.. Each and every request should pass through the corresponding HTTPModule to reach to HTTPHandler, this list of module are configured by the HTTPApplication.

Now, the concept comes called “HTTPPipeline”. It is called a pipeline because it contains a set of HttpModules ( For Both Web.config and Machine.config level) that intercept the request on its way to the HttpHandler. HTTPModules are classes that have access to the incoming request. We can also create our own HTTPModule if we need to handle anything during upcoming request and response.

HTTP Handlers are the endpoints in the HTTP pipeline. All request that are passing through the HTTPModule should reached to HTTPHandler.  Then  HTTP Handler  generates the output for the requested resource. So, when we requesting for any aspx web pages,   it returns the corresponding HTML output.
All the request now passes from  httpModule to  respective HTTPHandler then method and the ASP.NET Page life cycle starts.  This ends the IIS Request processing and start the ASP.NET Page Lifecycle.

Conclusion

When client request for some information from a web server, request first reaches to HTTP.SYS of IIS. HTTP.SYS then send the request to respective  Application Pool. Application Pool then forward the request to worker process to load the ISAPI Extension which will create an HTTPRuntime Object to Process the request via HTTPModule and HTTPHanlder. After that the ASP.NET Page LifeCycle events starts.

Preliminary Request Processing on IIS 6.0 in Workder Process Isolation Mode

Before an IIS process receives a request to execute, some preliminary processing occurs that is described in the following steps:

1. A request arrives at HTTP.sys.
2. HTTP.sys determines if the request is valid. If the request is not valid, it sends a code for an invalid request back to the client.
3. If the request is valid, HTTP.sys checks to see if the request is for static content (HTML) because static content can be served immediately.
4. If the request is for dynamic content, HTTP.sys checks to see if the response is located in its kernel-mode cache.
5. If the response is in the cache, HTTP.sys returns the response immediately.
6. If the response is not cached, HTTP.sys determines the correct request queue, and places the request in that queue.
7. If the queue has no worker processes assigned to it, HTTP.sys signals the WWW service to start one.
8. The worker process pulls the request from the queue and processes the request, evaluating the URL to determine the type of request (ASP, ISAPI, or CGI).
9. The worker process sends the response back to HTTP.sys.
10. HTTP.sys sends the response back to the client and logs the request, if configured to do so.

IIS 6.0 Process Model and Request Processing

Before starting with a virtual directory and Application Pool and all other stuff, let us have a quick look into the IIS 6.0 Process module and IIS request processing. This topic is a huge one. Here I am just giving you an overview.
We can divide the whole architecture into two layers.

• Kernel Mode
• HTTP.SYS
• User Mode
• Web Admin Service
• Virtual Directory
• Application Pool

IIS 6.0 Process module

As per the above diagram, IIS has two modes, Kernel and User. HTTP.SYS is the heart of kernel mode which accepts raw requests from the client and pass it to a particular application pool. Below are the steps of IIS request processing.

1. Client requests for a page from the browser by hitting the site URL.
2. Request comes to kernel level. HTTP.SYS catches the requests and creates a separate queue for each and every application pool.
Note: Whenever we create an application pool, IIS automatically registers the pool with HTTP.SYS to identify it during request processing.
Then HTTP.SYS forwards the request to the Application Pool.

3. A request coming to the application pool means the worker process (w3wp.exe) starts action by loading the ISAPI Filter.
4. Based on the requested resource, w3wp.exe loads "aspnet_isapi.dll" for an APSX page and starts an HTTPRuntime which is the entry point of an application.
5. Then the HttpRuntime.ProcessRequest method signals the start of processing.
6. The HttpContext object represents the context of the currently active request, as it contains references to objects you can access during the request lifetime, such as Request, Response, Application, Server, and Cache.
7. The HttpRuntime creates a pool of HttpApplication objects.
8. The request passes through the HTTP Pipeline.
9. HTTP Modules are executed against the request until the request hits the ASP.NET page HTTP Handler.
10. Once the request leaves the HTTP Pipeline, the Page life cycle starts.

If you want to know the details of IIS request processing, I will suggest you read the article ASP.NET Internals: Request Architecture.

Deploying Your Web Sites on IIS

In this section, I discuss how to host a site on IIS, how to create a virtual directory, configure a virtual directory, etc. Let's start with virtual directory creation.

Creating a Virtual Directory

There are various way to host a web application on IIS. Visual Studio has some inbuilt features to host and create a virtual directory on IIS directly. Here is one of my articles on hosting a site on IIS from Visual Studio. But in this section, Idiscuss the basic steps for creating a virtual directory.
First, right click on Default web sites > New > Virtual Directory.

Virtual directory creation

By selecting "Virtual Directory...", the virtual directory creation wizard will start. Click on "Next".

Virtual directory creation

Give the "Alias" name and proceed for "Next". The alias name is your virtual directory name.

Virtual directory creation

As its name implies, a "virtual directory" does not contain any physical file. We need to define the physical file path that it will refer to. We have to browse the physical path over here.

Virtual directory creation

Now based on your requirements, you can select the check boxes and click on "Next". Generally, we select only the "Read" option.

Virtual directory creation: Permission settings

Below is a list of permissions that we can use:

• Read: It is the most basic and is mandatory to access webpages of your application.
• Run Scripts: It is required for ASPX pages, not for static HTML pages because ASPX pages need more permissions so they could conceivably perform operations.
• Execute: This allows the user to run an ordinary executable file or CGI application. This can be a security risk so only allow when it is really needed.
• Write: It allows to add, modify, or remove files from the web server. This should never be allowed.
• Browse: This allows one to retrieve a full list of files in a virtual directory even if the contents of the files are restricted. It is generally disabled.

You are done! The virtual directory has been created successfully. You will get a final message. Click on "Finish" to close the window and move forward.

Virtual directory creation: Finish

There are other alternative options that you can use for creating a virtual directory.

1. Copy the physical directory to the wwwroot folder.
2. Physical Folder Properties > Web Sharing.

Configure Virtual Directory

The items listed below are very important for the configuration of any web application.

• Virtual Directory
• Documents
• Documents
• ASP.NET
• Directory Security
• Custom Errors

I have explained each of them step by step. Apart from them, a Virtual Directory can have settings like BITS Server Extension, HTTP Header, etc. I haven't covered those in this article. Let us start with the "Virtual Directory" tab.

Virtual Directory

This is the most important configuration section for a virtual directory. To open this tab, we need to select the newly created virtual directory.

Virtual directory configuration

Right click on it > Properties. The below screen will come up:

Virtual directory properties

Here we can change the local path (physical path). Before looking into other stuff, first look into the "Application Settings" section. It seems the application name is disabled. So first we need to click the "Create" button, which will enable the rest of the settings. Check the below image.

Virtual directory creation

Here we can change the execution setting and application pool name. Choosing "None" for Execute Permission will restrict the access to the web site. Now we will move to the "Documents" tab.

Documents

The Documents tab is used to set the default page of your web application. We can add or remove the page name in this section. To configure, we have to move to the "Documents" tab.

Virtual directory creation

This is useful when you want to access the site directly with the virtual directory name. For example, if your virtual directory name is "mywebsite" and your home page name is "home.aspx", then you can access the page as follows:

Collapse | Copy Code

http://<ip>/mywebsite/home.aspx

but if you define home.aspx in the Documents section, you need to only use this at the address bar to access the site:

Collapse | Copy Code

http://<ip>/mywebsite

ASP.NET

If IIS is registered with multiple .NET Framework versions, the ASP.NET version dropdown list shows all of them. But based on the application, we need to change the framework version. E.g.: If our application was developed in .NET 2.0, then the version should be 2.0.X.X.

ASP.NET version selection

Tip: If .NET Framework is already installed in your system when you are installing IIS, then ASP.NET will not be registered with IIS. So if you host an application on IIS, it will not work. To register IIS with the ASP.NET version, you need to run the aspnet_regiis -i command from the command prompt. This will automatically register the .NET Framework with your IIS.
For more info, please read this.

Directory Security

Directory security enables all kinds of security access for your web application. For directory, we need to move to the "Directory Security" tab.

Directory security settings

Click on the "Edit" button to modify the directory security settings. After clicking on the Edit button, the below screen will come up.

Directory security settings

Below are the commonly used IIS security settings:

• Anonymous
• Integrated Windows Authentication
• Basic Authentication
• Digest Authentication

Anonymous

Anonymous authentication means the site is accessible to all. This is the default authentication mode for any site that is hosted on IIS, and it runs under the "IUSR_[ServerName]" account. We can change it by clicking on the "Browse" button.

Integrated Windows Authentication

This authentication mode is generally used for Intranet sites. Users are authenticated from the Active Directory. Integrated Windows authentication is also known as NTLM authentication. If browser settings automatically login for trusted sites for Windows authentication then the site will be logged in automatically with the Windows user credentials.

Basic Authentication

This is supported by all browsers and is a part of the HTTP standard. This shows a login dialog control which accepts the user name and password. The user ID and password are passed to IIS to authenticate the user from the Windows credentials.

Digest Authentication

The disadvantages of Basic authentication mode is that it sends a password as plain text. Digest authentication does almost the same thing as basic authentication but it sends the "hash" of the password rather than sending plain text.
Integrated Windows, Basic Authentication, and Digest Authentication use Active Directory to authenticate the user.
Note: There are many things related with IIS and ASP.NET Security configuration. I am not covering all these in detail. I am just giving a brief overview so that you are comfortable with all this stuff.
For configuring SSL, please read the reference link that I have provided in the References section.

Custom Errors

The Custom Errors tab allows us to specify the error page that will be displayed for any specific type of HTTP Error.

Directory security settings

We can also customize the setting at our application level by configuring the web.config settings or changing the htm file path by clicking on the "Edit" button.
This is all about the basic overview of creation of virtual directories and setting up. Hope you are now comfortable with all this stuff.

Application Pool

Application pool is the heart of a website. An Application Pool can contain multiple web sites. Application pools are used to separate sets of IIS worker processes that share the same configuration. Application pools enable us to isolate our web application for better security, reliability, and availability. The worker process serves as the process boundary that separates each application pool so that when a worker process or application is having an issue or recycles, other applications or worker processes are not affected.

Application pool - IIS

Generally we do it in our production environment. The main advantages of using an application pool is the isolation of worker processes to differentiate sites and we can customize the configuration for each application to achieve a certain level of performance. The maximum number of application pools that is supported by IIS is 2000.
In this section, I have discussed about the creation of application pools, application pool settings, and assigning an application pool to a web site.

How to Create an Application Pool?

Application pool creation in IIS 6.0 is a very simple task. There are two different ways by which we can create an application pool. There is a pre-defined application pool available in IIS 6.0, called "DefaultApplicationPool". Below are the two ways to create an application pool:

• Create New Application Pool
• Create From Existing Configuration File

Create a New Application Pool

First of all, we need to open the IIS Configuration Manager. Then right click on Application Pool and go to New > Application Pool.

Create new application pool

The below screen will appear, where we need to mention the application pool name.

New application pool name

When we create a new application pool, we can use the default application setting for it. The selection of "Default Settings" means by default the application pool setting will be the same as the IIS default settings. If we want to use the configuration of an existing application pool, we need to select the section option "Use existing application pool as template". Selecting this option will enable the application pool name dropdown.

Application pool template selection

If we select an existing application pool as a template, the newly created application pool should have the same configuration of the template application pool. This reduces the time for application pool configuration.
That is all about creating a new application pool. Now let us have a look at the creation of an application pool from an existing XML configuration file.

Create From Existing Configuration File

We can save the configuration of an application pool into an XML file and create a new application pool from that. This is very useful during the configuration of an application pool in a Web Farm where you have multiple web servers and you need to configure the application pool for each and every server. When you are running your web application on a Load Balancer, you need to uniquely configure your application pool.
So first of all, you need to save the application pool configuration in a server. Check the below image for details.

Application pool template selection

During this operation, we can set the password for the configuration file which will be asked during the import of the application pool on another server. When we click on "Save Configuration to a file", the below screen will appear.

Save configuration as XML file

Where we need to provide the file name and location. If we want, we can set a password to encrypt the XML file. Below is a part of that XML:

Collapse | Copy Code

Location ="inherited:/LM/W3SVC/AppPools/StateServerAppPool"
AdminACL="49634462f0000000a4000000400b1237aecdc1b1c110e38d00"
AllowKeepAlive="TRUE"
AnonymousUserName="IUSR_LocalSystem"
AnonymousUserPass="496344627000000024d680000000076c20200000000"
AppAllowClientDebug="FALSE"
AppAllowDebugging="FALSE"
AppPoolId="DefaultAppPool"
AppPoolIdentityType="2"
AppPoolQueueLength="1000"
AspAllowOutOfProcComponents="TRUE"
AspAllowSessionState="TRUE"
AspAppServiceFlags="0" 
AspBufferingLimit="4194304"
AspBufferingOn="TRUE"
AspCalcLineNumber="TRUE"
AspCodepage="0"pre>

Now we can create a new application pool for this configuration file. While creating a new application pool, we have to select the "Application Pool ( From File )" option as shown in the below figure.

Application pool creation from a configuration file

When we select this option, a screen will come where we need to enter the file name and the password of that file.

Application pool creation from configuration file

Select the file and click on the "Read File" button. This will show you the imported application pool name. Click "OK" to import the full configuration.

Application pool creation from configuration file

Here we need to mention the new application pool name or we can have another option where we can replace an existing application pool. For moving ahead, we need to provide the password.

Password to import application pool configuration

This is the last step for creating a new application pool from an existing configuration file.

Configure Application Pool Properties

This is one of the most important tasks for web server configuration and this is important when we are hosting on a production server. As I have already discussed, the application pool is the heart of any web application hosted on IIS. We need to know each and every configuration of the application pool. To start configuration, we need to go to the Properties of the application pool.

Application pool properties

We need to configure the following things in the application pool:

• Recycling
• Performance
• Health
• Identity

Recycling

Recycling the application pool means recycling the worker process (w3wp.exe) and the memory used for the web application. It is a very good practice to recycle the worker process periodically, which wll keep the application running smooth. There are two types of recycling related with the application pool:

• Recycling Worker Process - Predefined settings
• Recycling Worker Process - Based on memory

Recycling Worker Process - Predefined Settings

Worker process recycling is the replacing of the instance of the application in memory. IIS 6.0 can automatically recycle worker processes by restarting the worker processes that are assigned to an application pool and associated with websites. This improves web site performance and keeps web sites up and running smoothly.

Application pool recycling- Worker process

There are three types of settings available for recycling worker processes:

• In minutes
• Number of requests
• At a given time

Recycle Worker Process (In Minutes)

We can set a specific time period after which a worker process will be recycled. IIS will take care of all the current running requests.

Recycle Worker Process (Number of Requests)

We can configure an application with a given number of requests. Once IIS reaches that limit, the worker process will be recycled automatically.

Recycle Worker Process (In Minutes)

If we want to recycle the worker process at any given time, we can do that configuration on IIS. We can also set multiple times for this.

Application pool recycling - Worker process: Time setting

Recycling Worker Process - Based on Memory

Server memory is a big concern for any web application. Sometimes we need to clean up a worker process based on the memory consumed by it. There are two types of settings that we can configure in the application pool to recycle a worker process based on memory consumption. These are:

• Maximum virtual memory used
• Maximum used memory

Application pool recycling - Worker process.

At any time, if the worker process consumes the specified memory (at memory recycling settings), it will be recycled automatically.

What Happens During Application Pool Recycling

This is quite an interesting question. Based on the above settings, an application pool can be recycled any time. So what happens to the users who are accessing the site at that time? We do not need to worry about that. This process is transparent from the client. When you recycle an application pool, HTTP.SYS holds onto the client connection in kernel mode while the user mode worker process recycles. After the process recycles, HTTP.SYS transparently routes the new requests to the new worker process.

Performance

Moving to the Performance tab in the Properties dialog box results in the following output.

Application pool performance

To improve the performance of a web application, we can setup the performance settings of the application pool. We can set the shut down time of the worker process based on the ideal time. The worker process will be shut down at a given time period if it is ideal. Whenever a new requests comes, it will live again. Another important thing for improving the performance is "Web Garden".

Web Garden

Overview of Web Garden

By default, each application pool runs with a single worker process (W3Wp.exe). We can assign multiple worker processes with a single application pool. An application pool with multiple worker processes is called a Web Garden. Many worker processes with the same application pool can sometimes provide better throughput performance and application response time. And each worker process should have its own thread and memory space.

Web Garden (Application pool with multiple worker processes)

As Shown in the picture, in IIS Server, there may be multiple application pools and each application pool has at least a single worker process. A Web Garden should contain multiple worker processes.
There are certain restrictions in using a Web Garden with your web application. If we use Session Mode as "in proc", our application will not work correctly because the Session will be handled by a different worker process. To avoid this, we should use Session Mode as "out proc" and we can use "Session State Server" or "SQL-Server Session State".

How to Create a Web Garden?

We need to increase the number of worker processes on the Performance tab.

Web garden creation

Main advantage: The worker processes in a web garden share the requests that arrive for that particular application pool. If a worker process fails, another worker process can continue processing the requests.

Health

Now we move to the "Health" tab. When wel select the "Health" tab, it will show the following screen:

Health monitoring setting

IIS provides a couple of settings to improve the health of an application pool. There are also a few settings for measuring the worker process health. These are:

• Enable Pinging
• Enable Rapid-fail protection
• Startup time limit
• Shutdown time limit

Enable Pinging

This property specifies whether the WWW Publishing Service should periodically monitor the health of a worker process. Checking this option indicates to the WWW service to monitor the worker processes to ensure that worker processes are running and healthy. By default, it sets to 30s. This is also needed to check if a service is staying ideal or not. If it is ideal it can be shutdown until the next request comes. The Windows Activation Process maintains all this stuff.

Enable Rapid-fail Protection

When enabling Rapid Fail Protection, the application pool is shut down if there are a specified number of worker process crashing within a specified time period. When this happens, the WWW Publishing Service puts all applications in the application pool "out of service".
Failure Count: The default value for failure count is 5 minutes. This property specifies the maximum number of failures allowed within the number of minutes specified by the "Time Period" property before the application pool is shut down by Rapid Fail Protection. If the number of failure is more than the specified in a given time, the application pool should be put on "out of service mode".
Time period: This property specifies the number of minutes before the failure count for a process is reset. By default, it is set to 5 minutes.

Startup time limit

The Start up time limit property specifies the amount of time that the WWW Publishing Service should wait for a worker process to finish starting up and reporting to the WWW Service. In general it means the time taken to start a worker process.

Shutdown time limit

This is the shutdown time for a worker process. This is the time required to execute all old running worker process requests before it shuts down during recycle time.

Identity

This is the last and final setting for an application pool. An application pool has three types of identity: "Network Service" is the default Identify. "defaultappPool" also runs under the "Network Service" Identity. Below are the listed application pool identities with description:

Identity	Description
LocalSystem	A built-in account that has administrative privileges on the server. It can access both local and remote resources. For any kind accessing of server files or resources, we have to set the Identity of the application pool to Local System.
LocalServices	Built-in account has privileges of an authenticated local user account. It does not have any network access permission.
NetworkServices	This is the default Identity of an application pool. NetworkServices has privileges of an authenticated local user account.

Navigating to the Identity tab will show the following screen:

Application pool identity configuration

We can also configure the application pool under a given user account. For that, we need to select the "Configurable" option on "Identity" tab.
This is all about the application pool. Hope now you have a very good understanding on what application pool is, how to create and configure the application pool.
Q: You are using a file upload control in your web application and it is working fine on Visual Studio but when you host the same code on IIS, it is not working. This is a very common problem in web hosting when file upload is involved.
A: When a web application runs under Visual Studio - ASP.NET engine integrated with visual studio takes care of all the executions. And this engine has sufficient rights so that it can write data on your disk. But when you host the site on IIS, as I have already mentioned, it runs under the "Network Services" Identity, which has very minimum rights on your system. The user can only have read access on the site. So for resolving file upload issues, you need to change the Identity of the application pool from "Network Service" to "Local System". Local System identity means the client can have write access on your hard drive. This will resolve your issue of file uploading on the server.
You can also resolve this issue by giving Write access permission to the file destination folder for "Everyone".

Enabling Web Service Extension

IIS 6.0 provides a certain type of configuration from where we can enable/disable web service extensions. If we want to prohibit/restrict any kind of extension, we need to select the extension and click on the "Prohibit" button.

Web Service extension vonfiguration

Note: If the ASP.NET v 2.0.X.XXXX extension is prohibited over here, you will not be able to access the site which is running on .NET 2.0.

Debugging Your Application That Hosted on IIS

If your site is hosted on IIS and we want to debug the site, the main thing that we need to do is attach a worker process with Visual Studio. There are two possible scenarios for debugging from IIS:

1. Site is hosted on local IIS server: Local IIS debugging
2. Site is hosted on remote IIS server: Remote IIS debugging

I have already published two complete articles on CodeProject on the above topic. Please refer to those for details.

Summary

To summarize, this article is for beginners who are trying to learn about IIS. This article gives a complete coverage of IIS, hosting sites on IIS, application pool creation, etc. I have also mentioned a few tips which are very commonly used in dealing with IIS. Hope this will help beginners struggling with site hosting on IIS and configuring it. There are so many things related with IIS and it is not possible to mention all of them in a single article. This is just an overview. I hope that in future I will publish a few more articles on IIS in detail. Please give your valuable feedback and suggestions in order to improve the article. Thank you.

Hypertext Transfer Protocol Stack (HTTP.sys)

The HTTP listener is part of the networking subsystem of Windows operating systems, and it is implemented as a kernel-mode device driver called the HTTP protocol stack (HTTP.sys). HTTP.sys listens for HTTP requests from the network, passes the requests onto IIS for processing, and then returns processed responses to client browsers.
In IIS 6.0, HTTP.sys replaced Windows Sockets API (Winsock), which was a user-mode component used by previous versions of IIS to receive HTTP requests and send HTTP responses. IIS 7 and above continue to rely on HTTP.sys for HTTP requests.
HTTP.sys provides the following benefits:

• Kernel-mode caching. Requests for cached responses are served without switching to user mode.
• Kernel-mode request queuing. Requests cause less overhead in context switching because the kernel forwards requests directly to the correct worker process. If no worker process is available to accept a request, the kernel-mode request queue holds the request until a worker process picks it up.
• Request pre-processing and security filtering.

asp.net request processing in IIS

This articles describes in detail on how a request is being processed in IIS. This has been explained with the features of IIS 6 and 5.1

Introduction to Internet Information Service(IIS)

IIS is a web server resides on windows operating systems that process the Http requests that come in. The file requested could be of any static or dynamic file types like image, css, .asp and aspx. The static files that requested with HTTP GET methods are processed by IIS itself.

It is as simple as looking up for the physical location of the file under the virtual directory and returning the response but dynamic files require some kind of server side processing while building the response to be sent back to the client. For .asp files the IIS redirects the request to the asp.dll which in turn process and returns the response. The same way the asp.net file extensions are mapped in IIS to be processed by the Asp.net process model.

AspNet ISAPI

ISAPI extensions are win32 dll built using vc++ which can be loaded into the http server to extend the web server functionality. Aspnet_ISAPI is an inherent component in IIS that receives and dispatches the request. IIS also contains an important component ISAPI Filter that interfere each request and used to modify the request/response data.
The asp.net specific file extensions (*.aspx,*.asmx,*.ashx) are configured in the IIS against the AspNet_ISAPI.dll. These extension mappings are stored on metabase in IIS. When the request is made against these extensions, they are redirected to the AspNet_Isapi.dll to be processed.

aspnet_regiis � I
This command installs the script map into the IIS metabase for the .net extensions that are served by the aspnet_isapi.dll.

When the http request (*.aspx) is invoked, it reaches the IIS and IIS checks the extensions configured on metabase and redirects it to the aspnet_isapi.dll if the requested file is of the type .aspx/.asmx/.ashx.
Aspnet_isapi is responsible to create the worker process which in turn loads the Asp.Net Runtime. It also monitors the worker process and recycles it when it is required. The implementation and hosting of aspnet_isapi differs in IIS5 and IIS6.

IIS 5.1

This version of IIS is used in win XP and 2000 machines. We will explore the IIS 5 process model to compare the IIS 6 which is pertained for more scalable and reliable. Aspnet_isapi is directly hosted with in the IIS 5. Once the IIS receives the request it verifies the file extension and sent across it to the Aspnet_ISAPI. Aspnet_isapi passes the control to Asp.Net worker process (aspnet_wp) and communicates with this process through the named pipes for subsequent communication.


Every application configured on IIS run on the same worker process. These applications are abstracted and isolated through the Application Domain where each application shares their own process. When the request is initiated for the first time against an application, App-domain is created in the worker process and the request is processed through the Asp.Net run-time.

The limitation of this process model is if one application is crashed it will bring down all the applications that have been loaded on the worker process. We can have only one worker process for a CPU in IIS5 except the web garden model.

Asp.Net Runtime

Once the worker process is assigned for the request, the aspnet_isapi.dll loads the HttpRuntime environment. The process involved in HttpRuntime is often referred as Asp.NetPipeline process as it traverse through a set of classes that assists in serving the request. Each request has been assigned with an instance of HttpApplication object which binds some predefined events for the application. In most cases this objects represents the global.asax which inherits the HttpApplication. The HttpApplication is also tied with a set of HttpModules registered for the application.

The HttpModules intercepts the request and read/modifies the request. HttpModules are written with the logic to intercept the request with the HttpApplication events.Asp.net ship in with the built-in modules like SessionStateModule, AuthenticationModule and AuthorizationModules etc. Once the request passes through the HttpModules, it reaches HttpHandler which actually process the request and returns the response. The HttpHandler selected to process the request is based on the extension of the request.*.aspx is served by ASP.NET page handler and Web service handler for the *.asmx.

IIS 6

IIS 6 was designed keeping in mind of the limitation of IIS5, mainly reliability. The Asp.Net pipeline process (HttpModules, HttpHandlers) remains the same as of earlier version. IIS 6 introduced the concept of application pool where one or more web sites are grouped and served by separate worker process for each application pool. This enables the IIS to have multiple worker processes that can hold one or more applications in it and distinguish the configuration settings. This model is called Worker process isolation mode. This dramatically improves the scalability of the requests. And also the aspnet_ispai has been moved into the worker process avoiding the user level impact on IIS.
Http.Sys is responsible for receiving the request and returning the response.

It also acts to return the cached version of the URL if it exists. As Http.Sys limitation is not exposed to the worker process, even at the time of w3wp.exe failure, it continues to accept the request. Each application pool is associated with a request queue in http.sys. Whenever a request is received by IIS, the Http.Sys examines the URL and pushes it to the appropriate request queue. The worker process (w3wp.exe) created for the application pool then collects the request from the request queue and loads the aspnet_isapi. The Aspnet_Isapi in turn loads the Asp.Net runtime and processes the request. The Asp.net runtime remains the same as of IIS 5.

Here the worker processes (w3wp.exe) are isolated giving the autonomy for the set of application in defining their own configurations. So in any case of outage or crash on worker process kills only that process rather than bring down the whole IIS. IIS 6 also supports the IIS 5.0 Isolation Mode model to provide compatibility for the classic applications. WWW Service in IIS is responsible for Administration and Monitoring the worker process. This component gets alive as soon as the IIS started and updates the [routing table] in Http.sys, when a web site is added or deleted. The Http.Sys then uses this routing table to route the incoming request to the right application pool. This component is responsible for the worker process recycling, health monitoring and creation of w3wp.exe. In Worker process isolation mode, the worker process is recycled depending on the configuration or when the worker process fails unexpectedly. At the time of recycling the new worker process is created before stopping the existing one. So users never experience the outage.

Conclusion

This article we have seen how the asp.net request is processed by the IIS. Also distinguishes the process model improvement in IIS 6 against the ISS 5. The Asp.net Runtime is the essential component in the asp.net request life cycle; we have discussed it though not in detail

Introduction

In this article, we will try to understand what the different events are which take place right from the time the user sends a request, until the time the request is rendered on the browser. So we will first try to understand the two broader steps of an ASP.NET request and then we will move into different events emitted from ‘HttpHandler’, ‘HttpModule’ and ASP.NET page object. As we move in this event journey, we will try to understand what kind of logic should go in each and every one of these events.
This is a small Ebook for all my .NET friends which covers topics like WCF, WPF, WWF, Ajax, Core .NET, SQL, etc. You can download the same from here or else you can catch me on my daily free training here.

The Two Step Process

From 30,000 feet level, ASP.NET request processing is a 2 step process as shown below. User sends a request to the IIS:

• ASP.NET creates an environment which can process the request. In other words, it creates the application object, request, response and context objects to process the request.
• Once the environment is created, the request is processed through a series of events which is processed by using modules, handlers and page objects. To keep it short, let's name this step as MHPM (Module, handler, page and Module event), we will come to details later.

In the coming sections, we will understand both these main steps in more detail.

Creation of ASP.NET Environment

Step 1: The user sends a request to IIS. IIS first checks which ISAPI extension can serve this request. Depending on file extension the request is processed. For instance, if the page is an ‘.ASPX page’, then it will be passed to ‘aspnet_isapi.dll’ for processing.

Step 2: If this is the first request to the website, then a class called as ‘ApplicationManager’ creates an application domain where the website can run. As we all know, the application domain creates isolation between two web applications hosted on the same IIS. So in case there is an issue in one app domain, it does not affect the other app domain.

Step 3: The newly created application domain creates hosting environment, i.e. the ‘HttpRuntime’ object. Once the hosting environment is created, the necessary core ASP.NET objects like ‘HttpContext’ , ‘HttpRequest’ and ‘HttpResponse’ objects are created.

Step 4: Once all the core ASP.NET objects are created, ‘HttpApplication’ object is created to serve the request. In case you have a ‘global.asax’ file in your system, then the object of the ‘global.asax’ file will be created. Please note global.asax file inherits from ‘HttpApplication’ class.
Note: The first time an ASP.NET page is attached to an application, a new instance of ‘HttpApplication’ is created. Said and done to maximize performance, HttpApplication instances might be reused for multiple requests.

Step 5: The HttpApplication object is then assigned to the core ASP.NET objects to process the page.

Step 6: HttpApplication then starts processing the request by HTTP module events, handlers and page events. It fires the MHPM event for request processing.
Note: For more details, read this.

The below image explains how the internal object model looks like for an ASP.NET request. At the top level is the ASP.NET runtime which creates an ‘Appdomain’ which in turn has ‘HttpRuntime’ with ‘request’, ‘response’ and ‘context’ objects.

Process Request using MHPM Events Fired

Once ‘HttpApplication’ is created, it starts processing requests. It goes through 3 different sections ‘HttpModule’ , ‘Page’ and ‘HttpHandler’. As it moves through these sections, it invokes different events which the developer can extend and add customize logic to the same.
Before we move ahead, let's understand what are ‘HttpModule’ and ‘HttpHandlers’. They help us to inject custom logic before and after the ASP.NET page is processed. The main differences between both of them are:

• If you want to inject logic based in file extensions like ‘.ASPX’, ‘.HTML’, then you use ‘HttpHandler’. In other words, ‘HttpHandler’ is an extension based processor.
  
• If you want to inject logic in the events of ASP.NET pipleline, then you use ‘HttpModule’. ASP.NET. In other words, ‘HttpModule’ is an event based processor.
  

You can read more about the differences from here.
Below is the logical flow of how the request is processed. There are 4 important steps MHPM as explained below:

Step 1(M: HttpModule): Client request processing starts. Before the ASP.NET engine goes and creates the ASP.NET HttpModule emits events which can be used to inject customized logic. There are 6 important events which you can utilize before your page object is created BeginRequest, AuthenticateRequest, AuthorizeRequest, ResolveRequestCache, AcquireRequestState and PreRequestHandlerExecute.

Step 2 (H: ‘HttpHandler’): Once the above 6 events are fired, ASP.NET engine will invoke ProcessRequest event if you have implemented HttpHandler in your project.

Step 3 (P: ASP.NET page): Once the HttpHandler logic executes, the ASP.NET page object is created. While the ASP.NET page object is created, many events are fired which can help us to write our custom logic inside those page events. There are 6 important events which provides us placeholder to write logic inside ASP.NET pages Init, Load, validate, event, render and unload. You can remember the word SILVER to remember the events S – Start (does not signify anything as such just forms the word) , I – (Init) , L (Load) , V (Validate), E (Event) and R (Render).

Step4 (M: HttpModule): Once the page object is executed and unloaded from memory, HttpModule provides post page execution events which can be used to inject custom post-processing logic. There are 4 important post-processing events PostRequestHandlerExecute, ReleaserequestState, UpdateRequestCache and EndRequest.
The below figure shows the same in a pictorial format.

In What Event Should We Do What?

The million dollar question is in which events should we do what? Below is the table which shows in which event what kind of logic or code can go.

Section	Event	Description
HttpModule	BeginRequest	This event signals a new request; it is guaranteed to be raised on each request.
HttpModule	AuthenticateRequest	This event signals that ASP.NET runtime is ready to authenticate the user. Any authentication code can be injected here.
HttpModule	AuthorizeRequest	This event signals that ASP.NET runtime is ready to authorize the user. Any authorization code can be injected here.
HttpModule	ResolveRequestCache	In ASP.NET, we normally use outputcache directive to do caching. In this event, ASP.NET runtime determines if the page can be served from the cache rather than loading the patch from scratch. Any caching specific activity can be injected here.
HttpModule	AcquireRequestState	This event signals that ASP.NET runtime is ready to acquire session variables. Any processing you would like to do on session variables.
HttpModule	PreRequestHandlerExecute	This event is raised just prior to handling control to the HttpHandler. Before you want the control to be handed over to the handler any pre-processing you would like to do.
HttpHandler	ProcessRequest	Httphandler logic is executed. In this section, we will write logic which needs to be executed as per page extensions.
Page	Init	This event happens in the ASP.NET page and can be used for: Creating controls dynamically, in case you have controls to be created on runtime. Any setting initialization. Master pages and the settings. In this section, we do not have access to viewstate, postedvalues and neither the controls are initialized.
Page	Load	In this section, the ASP.NET controls are fully loaded and you write UI manipulation logic or any other logic over here.
Page	Validate	If you have valuators on your page, you would like to check the same here.
	Render	It’s now time to send the output to the browser. If you would like to make some changes to the final HTML which is going out to the browser, you can enter your HTML logic here.
Page	Unload	Page object is unloaded from the memory.
HttpModule	PostRequestHandlerExecute	Any logic you would like to inject after the handlers are executed.
HttpModule	ReleaserequestState	If you would like to save update some state variables like session variables.
HttpModule	UpdateRequestCache	Before you end, if you want to update your cache.
HttpModule	EndRequest	This is the last stage before your output is sent to the client browser.

A Sample Code for Demonstration

With this article, we have attached a sample code which shows how the events actually fire. In this code, we have created a ‘HttpModule’ and ‘Httphandler’ in this project and we have displayed a simple response write in all events, below is how the output looks like.
Below is the class for ‘HttpModule’ which tracks all events and adds it to a global collection.

Collapse | Copy Code

public class clsHttpModule : IHttpModule
{
...... 
void OnUpdateRequestCache(object sender, EventArgs a)
{
objArrayList.Add("httpModule:OnUpdateRequestCache");
}
void OnReleaseRequestState(object sender, EventArgs a)
{
objArrayList.Add("httpModule:OnReleaseRequestState");
}
void OnPostRequestHandlerExecute(object sender, EventArgs a)
{
objArrayList.Add("httpModule:OnPostRequestHandlerExecute");
}
void OnPreRequestHandlerExecute(object sender, EventArgs a)
{
objArrayList.Add("httpModule:OnPreRequestHandlerExecute");
}
void OnAcquireRequestState(object sender, EventArgs a)
{
objArrayList.Add("httpModule:OnAcquireRequestState");
}
void OnResolveRequestCache(object sender, EventArgs a)
{
objArrayList.Add("httpModule:OnResolveRequestCache");
}
void OnAuthorization(object sender, EventArgs a)
{
objArrayList.Add("httpModule:OnAuthorization");
}
void OnAuthentication(object sender, EventArgs a)
{

objArrayList.Add("httpModule:AuthenticateRequest");
}
void OnBeginrequest(object sender, EventArgs a)
{

objArrayList.Add("httpModule:BeginRequest");
}
void OnEndRequest(object sender, EventArgs a)
{
objArrayList.Add("httpModule:EndRequest");
objArrayList.Add("<hr>");
foreach (string str in objArrayList)
{
httpApp.Context.Response.Write(str + "<br>") ;
}
} 
}

Below is the code snippet for ‘HttpHandler’ which tracks ‘ProcessRequest’ event.

Collapse | Copy Code

public class clsHttpHandler : IHttpHandler
{
public void ProcessRequest(HttpContext context)
{
clsHttpModule.objArrayList.Add("HttpHandler:ProcessRequest");
context.Response.Redirect("Default.aspx");
}
}

We are also tracking all the events from the ASP.NET page.

Collapse | Copy Code

public partial class _Default : System.Web.UI.Page 
{
protected void Page_init(object sender, EventArgs e)
{

clsHttpModule.objArrayList.Add("Page:Init");
}
protected void Page_Load(object sender, EventArgs e)
{
clsHttpModule.objArrayList.Add("Page:Load");
}
public override void Validate() 
{
clsHttpModule.objArrayList.Add("Page:Validate");
}
protected void Button1_Click(object sender, EventArgs e)
{
clsHttpModule.objArrayList.Add("Page:Event");
}
protected override void Render(HtmlTextWriter output) 
{
clsHttpModule.objArrayList.Add("Page:Render");
base.Render(output);
}
protected void Page_Unload(object sender, EventArgs e)
{
clsHttpModule.objArrayList.Add("Page:UnLoad");
}}

Below is how the display looks like with all events as per the sequence discussed in the previous section.

Zooming ASP.NET Page Events

In the above section, we have seen the overall flow of events for an ASP.NET page request. One of the most important sections is the ASP.NET page, we have not discussed the same in detail. So let’s take some luxury to describe the ASP.NET page events in more detail in this section.
Any ASP.NET page has 2 parts, one is the page which is displayed on the browser which has HTML tags, hidden values in form of viewstate and data on the HTML inputs. When the page is posted, these HTML tags are created in to ASP.NET controls with viewstate and form data tied up together on the server. Once you get these full server controls on the behind code, you can execute and write your own login on the same and render the page back to the browser.

Now between these HTML controls coming live on the server as ASP.NET controls, the ASP.NET page emits out lot of events which can be consumed to inject logic. Depending on what task / logic you want to perform, we need to put this logic appropriately in those events.
Note: Most of the developers directly use the page_load method for everything, which is not a good thought. So it’s either populating the controls, setting view state, applying themes, etc., everything happens on the page load. So if we can put logic in proper events as per the nature of the logic, that would really make your code clean.

Seq	Events	Controls Initialized	View state Available	Form data Available	What Logic can be written here?
1	Init	No	No	No	Note: You can access form data etc. by using ASP.NET request objects but not by Server controls.Creating controls dynamically, in case you have controls to be created on runtime. Any setting initialization.Master pages and them settings. In this section, we do not have access to viewstate , posted values and neither the controls are initialized.
2	Load view state	Not guaranteed	Yes	Not guaranteed	You can access view state and any synch logic where you want viewstate to be pushed to behind code variables can be done here.
3	PostBackdata	Not guaranteed	Yes	Yes	You can access form data. Any logic where you want the form data to be pushed to behind code variables can be done here.
4	Load	Yes	Yes	Yes	This is the place where you will put any logic you want to operate on the controls. Like flourishing a combobox from the database, sorting data on a grid, etc. In this event, we get access to all controls, viewstate and their posted values.
5	Validate	Yes	Yes	Yes	If your page has validators or you want to execute validation for your page, this is the right place to the same.
6	Event	Yes	Yes	Yes	If this is a post back by a button click or a dropdown change, then the relative events will be fired. Any kind of logic which is related to that event can be executed here.
7	Pre-render	Yes	Yes	Yes	If you want to make final changes to the UI objects like changing tree structure or property values, before these controls are saved in to view state.
8	Save view state	Yes	Yes	Yes	Once all changes to server controls are done, this event can be an opportunity to save control data in to view state.
9	Render	Yes	Yes	Yes	If you want to add some custom HTML to the output this is the place you can.
10	Unload	Yes	Yes	Yes	Any kind of clean up you would like to do here.