Introduction
When you browse a page of your ASP.NET application on the website, you get a page in exchange for a URL in the browser. There are a lot of things happening behind the screen though. In this article, I am going to go through the various tasks and events involved in the ASP.NET request processing cycle.
Web Server
Web Server is where people host their websites and web applications. It can be considered as a software or hardware or both, working together. A web server hosts our site/applications and responds with a result of a page when we request for a page in the browser.
IIS
IIS is a web server offered by Microsoft that runs on Windows machine. IIS has its own ASP.NET process engine to handle the ASP.NET requests.
Note: When we run our ASP.NET web application from Visual Studio IDE, it integrates the ASP.NET Engine which is a part of IIS Express built into VS and responsible for executing all kinds of ASP.NET requests and responses.
IIS Architecture
HTTP stack also known as HTTP.SYS is an HTTP listener and is a part of networking subsystem of Windows. It is implemented as a kernel-mode device driver. Its job is to pick up HTTP requests from the network and send them to IIS for processing. Older versions of IIS were using Windows Sockets API, popularly known as Winsock, as their protocol listener. It was implemented as the user-mode component. IIS 6.0 and later versions started using HTTP.SYS. Once the request is processed, IIS returns the response to HTTP.SYS and that, in turn, returns the response to the requestor. HTTP.SYS works as a protocol listener starting from IIS 6.0.
IIS 6.0 architecture has two layers:
- Kernel mode
- User mode
Kernel mode has HTTP.SYS and User mode has World Wide Web Service (WWW Service) and Windows Process Activation Service (WAS).
HTTP.SYS assigns the request to the respective queue for processing. If there is no worker process assigned to a queue, HTTP.SYS signals WWW Service to start one. When an application pool is created, IIS creates a request queue in HTTP.SYS and registers it with the worker process(es) that serves the application pool.
IIS 7 split up the functionality handled by World Wide Web Publishing Service and shared them between two services namely WWW Service (W3Svc) and WAS. WWW Service serves as the listener adapter for HTTP.SYS.
Duties of the WWW Service are,
- Configure HTTP.SYS
- Update HTTP.SYS when there is a configuration change
- Notify WAS when a request enters kernel-mode request queue aka request queue.
- Provide performance counters for IIS cache and for websites for monitoring performance.
WAS manages application pool configuration and worker processes. It supports HTTP and non-HTTP sites. WAS can run even without WWW service. For example, you can use WCF listener adapter such as NetTCPActivator for managing web service.
WAS reads information from ApplicationHost.config file and passes the information to listener adapters (eg: WWW service) on the server (eg: IIS 7).
![ASP.NET]()
If ApplicationHost.config changes WAS gets a notification and it updates the listener adapter with the new information.
![ASP.NET]()
How IIS process an ASP.NET Request
It all starts with the user requesting for an application resource from the Web server.
HTTP.SYS which is the Kernel mode HTTP listener for the IIS 6.0 and later versions, picks up the request and passes on to the web server (IIS).
HTTP.SYS finds out the request is for which application. Each application hosted in IIS is mapped to an application pool.
All the application pools are registered with HTTP.SYS at the time of their creation and HTTP.SYS has their ID’s.
HTTP.SYS passes the request to WAS and which in turn, passes the request to the respective application pool.
If the application pool doesn’t have a worker process or “w3wp.exe” running, WAS will start one.
If the worker process is busy running other application, the request will be stored in the kernel mode request queue in HTTP.SYS for the application pool. Worker process will pick the request from the queue when it is available.
Worker process (w3wp.exe) reads the URL of the request and loads the correct ISAPI extension. This is done by checking the extension of the requested file. ISAPI extension for ASP.NET will be invoked if the requested file extension is mapped to ASP.NET in IIS configuration. You can register file extensions in IIS and map to ASP.NET. Then, IIS will pass the requests for that files to the ASP.NET ISAPI extension. ISAPI extension for ASP.NET is aspnet_isapi.dll. While installing ASP.NET in the server, it installs its ISAPI extension (aspnet_isapi.dll) and adds the mapping of default ASP.NET file extensions to aspnet_isapi.dll in IIS. In some cases, if IIS is installed after installing ASP.NET, the ISAPI extension may not get registered. We may need to do it using the aspnet_regiis command.
aspnet_isapi.dll initiates HttpRuntime. HttpRutime calls the ProcessRequest method in the page requested which starts processing of the request.
During this time, it also creates and initializes core objects such as HttpContext, HttpRequest, and HttpResponse.
After all the core application objects are initialized, the application is started by creating an instance of the HttpApplication class and represents the application. If the application has a Global.asax file, ASP.NET creates the instance of the Global.asax file instead which is derived from HttpApplication. The instance of this Global.asax class represents the application in this case.
For every request made to the application, corresponding HttpModules are called before it reaches the HttpHandler. This is called an HttpPipeline. These list of HttpModules are configured by the HttpApplication using Machine.config and Web.config. Your application’s Web.config file will have a default module for your application like below,
<httpModules>
<add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule, Microsoft.AI.Web" />
</httpModules>
You can register your custom module here if you want to handle any custom tasks during request or response.
The request then reaches the HttpHandler which is also known as the endpoint in the HttpPipeline. HttpHandler is responsible for processing the request and sending the HTML response back to the browser.
In simple words, we can tell that any class that implements IHttpHandler can serve as an HttpHandler. The most common handler is the ASP.Net Page handler. When you request for a .aspx page, it reaches the page handler. ProcessRequest method of the IHttpHandler interface which is implemented in the handler then be invoked by the HttpRuntime.
After the request reaches the HttpHandler, the IIS Request Processing cycle ends and ASP.NET page life cycle starts. In other words, we can tell that ASP.NET page life cycle events happens while the ProcessRequest method in the HttpHandler (asp.net page in case of a .aspx file) gets executed.
How an ASP.NET Request is Processed
When the user requests a resource from a web server, HTTP.SYS which is a part of IIS picks it up. HTTP.SYS then send the request to corresponding Application Pool. Application Pool then forwards the request to the worker process associated with it. Worker process loads the correct ISAPI Extension based on the extension of the requested file. ISAPI extension will then create an HTTPRuntime object which will create all the core application objects and HTTPApplication object. HttpHandler associated with the page is then invoked and which in turn invokes the ProcessRequest. It process the request and generates the response. The response is sent back to the browser by the HTTP.SYS.
I hope you have a basic understanding of the things happening behind an ASP.NET page request.
Thank you for reading!
Reference
- https://msdn.microsoft.com
- https://docs.microsoft.com
Refer for more detailed study
- https://msdn.microsoft.com/en-us/library/ms178473(v=vs.85).aspx
- https://msdn.microsoft.com/en-us/library/bb515343.aspx
- https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/isapicgirestriction/
- https://msdn.microsoft.com/library/ms178468.aspx