After having seen the overall process models that ASP.Net can possibly run under, we will now discuss the components of the ASP.Net pipeline – steps that ASP.Net performs on each request before it serves its response, these don’t differ based on process model. The process model just determines how the original request flows from the IIS gate into the CLR instance. Now, inside the CLR a pipeline of components act upon the request and actually processes it at each step.
In general the ASP.Net request goes through several managed components and finally lands at a class that actually handles the request. The managed components that participate in the ASP.Net pipeline can do several things to the request – read and edit the request, access and add cookies, order browser redirects, check against cached content, perform validations etc. At the end of the pipeline, the request morphs into an instance of a class that represents the requested ASP.Net resource.
Specifically in ASP.Net 2.0, this process has been significantly re-factored to involve several new components, most of which are customizable to various extents by developers.
These components of the ASP.Net pipeline, we will now understand what they are. It’s a bit easier to understand this concept saying that – the ultimate goal of the pipeline is to find a class that fully represents the requested ASP.Net resource. Note that if not found, such a class is created on the fly, compiled, and loaded in the AppDomain where the ASP.Net application runs. The components of the pipeline are as follows:
Components of the HTTP pipeline:
An instance of this class is responsible for returning a valid HttpApplication object that can handle the request. HttpApplicationFactory object maintains a pool of HttpApplication objects, and when invoked, it verifies that an AppDomain exists for the virtual folder targeted by the request. If the application is already running, the factory picks an HttpApplication out of the pool and passes it the request. A new HttpApplication object is created if an existing object is not available.
A running ASP.Net application is represented by a dynamically created class that inherits from HttpApplication. The source code of this dynamically generated class is created by parsing the global.asax file and its code file. The HttpApplication object determines the class that represents the resource being requested – typically, an ASP.net page, a Web Service, or perhaps a user control – and uses the proper handler factory to get an object that represents the requested resource.
The HttpApplication maintains a list of module objects that can filter and even modify the content of the request. Registered modules are called at several stages of the request processing as the request passes through the pipeline. Built in Http Modules are responsible for steps such as authentication, output caching, session state management, user profiling etc.
The page handler factory creates an instance of an object that represents the particular page requested. Analogous factory objects will do the same for web service, user control, custom handlers.
The page object created by the page factory inherits from the System.Web.UI.Page class (or a class derived from this), which in turn implements the IHttpHandler interface. The final step accomplished by the ASP.Net runtime is calling the HttpHandler’s ProcessRequest method on the page object. This call causes the page to execute the user defined code and generate the markup for the client.
That’s it for today. Thanks for joining!!! See you tomorrow. Tomorrow we will talk about the page handler factory in detail and in coming days we will deal with the dynamic compilation of pages.
Coordinator Daily .Net Feed Program