In other to effectively use asp.net or any of the framework that sits on top of it, it becomes vital for one to take a look under the hood so as to understand how the framework processes requests. The benefit of this extra effort apart from the nitty-gritty knowledge of the framework is that it will aide you in developing a very fast and efficient application geared for performance and speed.
In this article am going to try to illuminate the asp.net processing pipeline so as to shed more light on its inner workings and on how to take advantage of it. Before we begin our discussion about asp.net request processing cycle, I will like to get some definition cleared out of the way so as to ease our way into the major concept.
The pipeline pattern: Just like the typical pipes used to transfer a liquids from place to place. The pipeline pattern is a programming model that executes code and event in a parallel sequential fashion employing the use of buffers to temporarily hold the result as it passes through the pipeline. Yeah, that's textbook definition, but what the above definition is saying in essence is that the pipeline model executes code in this case request in a FIFO kind of way in that the output of way stage becomes the input of another stage and that as the execution is taking place in a parallel fashion it employs a temporary store to (i.e: buffer)to store its data so that it can move to the next in coming data. Now as it passes through the line, the original data comes out slightly modified before moving over to the next stage. This pattern works in a first come first serve basis thereby ensuring that requests do not topple each other.
Asp.net request processing pipeline.
When a client (for example a browser) sends an HTTP/HTTPS request to the server and the request arrives at the server, it is received by a protocol listener (HTTP.sys : Hypertext Transfer Protocol stack). This protocol listener is responsible for listening to protocol specific request(s) in IIS and returning response to the client.
Immediately it receives the requests, the Http.sys inside IIS syncs with the WWW (World Wide Web publishing service). This service is primarily responsible for connecting to HTTP.sys, updating it when configuration changes and notifying the WAS(Windows Process Activation Service) when request enters the request queue. The WWW then syncs with the ApplicationHost configuration file and receives configuration for the application pool and application (i.e: the virtual directory of the file being requested and other details).
When these communications with the application host config have taken place, the WWW then notifies the WAS that a request has entered the request queue. It is the duty of the WAS to manage application pool configuration and worker processes for both HTTP and non-HTTP requests. When the WAS is informed of the arrival of a request, it checks to see if there is an application pool servicing the type of request that entered the queue, if there is, the WAS then checks to see if the application pool has a worker process available to process the request, if true, the WAS then simply passes the request to the worker process for processing. On the other hand, if neither the application pool nor the worker process exists, the WAS will create one or both to service the request.
Then, it hands over the request to the worker process for servicing, and that is the request crossing the border between the IIS and ASP.NET web server. When the request enters the worker process, the aspnet_isapi.dll will be invoked, which will redirect the request through a named pipe to an instance of an appDomain inside the Asp.net worker process.
The worker process will at this point, initialize an instance of HttpRuntime class to process the request. This HttpRuntime will use the HttpApplicationFactory to figure out the application the request was sent to (NOTE: the pipeline sees a virtual directory as an application) if the HttpApplication class for the application is available, it will hand the request over otherwise it will initialize one before handing over the request.
The HttpApplication object
The HttpApplication object defines the methods, properties, and events that are common to all application objects. This object holds a collection of HTTP module objects which implements the IHTTPModule interface (IHttpModule species members which filters the HTTP request and response contents as it passes through the request pipeline by responding to events the HttpApplication raises at each stage of the pipeline).
Furthermore, the HttpApplication object will use the HttpHandlerFactory class to discover or create handlers as the case may be. These HTTP handlers implement the IHttpHandler and just as their name sounds, they handle the request by calling the
ProcessRequest(HttpContext context) and generate the appropriate response message for the client.
Now the response returns to the client following the same pipeline it came from. As it moves through the pipeline, the HttpModules will also be able to modify the message by attaching to the appropriate HttpApplication event.
As the request/response pair moves through the Asp.net pipeline in the form of HttpContext. This object serves as a container for HttpRequest, HttpResponse object and other properties vital for the execution of the request and transfer of response like the per-session state, User agent among others. It is this object that the HttpModules modifies to affect the request/response. So to plug into the Asp.net processing pipeline, one must implement a custom module through the implementation of the IHttpModule object but more on that later.
For futher readings on this topic, try