Process Request method in Page Life Cycle

Question

I need to understand the below statements

Statement - 1

The most common handler is an ASP.NET page handler that processes .aspx files. When users request an .aspx file, the request is processed by the page through the page handler.

Statement - 2

You might write your own, for example, to serve images etc from a database rather than from the web-server itself, or to write a simple POX service (rather than SOAP/WCF/etc)

Statement - 3

What is the importance of ProcessRequest in Page Life Cycle?

Answer 1

Definitions

• HTTP - A protocol that allows clients and servers to talk with each other.

• IIS - A Microsoft "web server". By "web server" I mean an application that does three things: listens for incoming HTTP Requests, handles them, and then replies with an HTTP response.

• ASP.NET - A framework built on top of .NET used to create custom logic for HTTP requests.

• ASP.NET Web Application - A type of Visual Studio project. These projects work, primarily, by integrating with a web server (e.g. IIS). Building doesn't create an executable of any kind.

• IIS Pipeline - The series of events an HTTP request goes through once it enters IIS.

• HTTP Handler - The primary logic for determining the HTTP Response to an HTTP Request. Only one HTTP handler is used per request. The handler is typically chosen by the extension of the requested resource. For example, if a .jpg, .png, or .gif (i.e. an image) is requested the handler could simply return the image. If a .php page were requested the handler could return the results of executing the PHP file. IIS comes with its own native handlers. ASP.NET adds to these and also allows you to write your own custom handlers.(as an example a list of handlers on an IIS website)

IIS and ASP.NET Web Applications

There is a complicated relationship between IIS and ASP.NET (from here forward ASP.NET will mean a web application unless otherwise noted). It can be difficult to tell where one begins and the other ends.

Perhaps the most important distinction between the two is that while IIS is a stand-alone application, ASP.NET relies on a server, like IIS, to run. This means there are several things IIS has to do (e.g. routing, authentication, and authorization) that ASP.NET can choose to get involved with or not.

ASP.NET is able to control where its custom code is injected into the IIS Request Pipeline by defining its own handlers and modules. Every module gets involved with every request using request pipeline events to tie in. Handlers, on the other hand, work alone. Only one will be chosen to act on a request.

One final thing worth noting is that IIS and ASP.NET can work together in one of two different modes, Classic or Integrated. I won't go into the difference here other than to say that for this answer it doesn't matter which mode you are in. The modes primarily affect how modules execute.

System.Web.UI.Page and IHttpHandler

As mentioned the ASP.NET framework allows you to create your own handlers to extend IIS. Handlers can either be made from scratch or by inheriting from pre-made handlers in the ASP.NET framework.

(Statement 1)The most notable of the pre-made handlers is System.Web.UI.Page. We can tell that this class is a handler because it implements IHttpHandler. This means that every time you create a new aspx page that inherits from System.Web.UI.Page you are creating your own custom handler that will handle a request for that page and return the proper HTML.

(Statement 2)If you'd like to make a handler from scratch you can do so by implementing IHttpHandler on your own classes. This interface only has one method ProcessRequest. When it is time for IIS to pass off to your handler it will call this method and pass the HttpContext for the request you are handling.

(Statement 3) The entire System.Web.UI.Page life-cycle occurs in Page's ProcessRequest method. If you use dotPeek to decompile System.Web.dll you can see everything ProcessRequest does. Some of the more notable things are firing all Page life-cycle events, rendering all WebControls as HTML, and DataBinding. So, in a sense, ProcessRequest is the Page life-cycle (or at least its implementation).

Answer 2

In order to keep this as approachable as possible, I'm going to focus on basic processing in IIS with ASP.NET WebForms and also glaze over some of the more involved details such as HttpModules. Much of this would also apply to an MVC or Apache/Mono environment, with some differences.

When IIS receives a request, it will attempt to match it to an ISAPI filter to handle it. Typically, the matching process is controlled by the extension of the file for the incoming request. In the case of ASP.NET, for example, the .aspx extension is mapped to the .NET ISAPI filter. The .NET ISAPI filter is responsible for processing that request and, under normal circumstances, finds the correct IHttpHandler instance and invokes it to ultimately serve the request. In the case of a WebForm, the match is often as simple as matching the name of the file requested with the page class that implements it.

In ASP.NET, a page is normally derrived from the class System.Web.UI.Page which implements the IHttpHandler interface. IHttpHandler has only a single method, ProcessRequest which the Page class implements for you. Page events and the page life cycle are not known to the handler - those are implementation details of the Page class itself. With respect to your question on the involvement of the HttpHandler during the page lifecycle, there is none. Once the ISAPI filter invokes the ProcessRequest method on the IHttpHandler interface, all other processing and events are a result of the Page class.

• This MSDN article, though outdated, provides a reasonable explanation of the high level page rendering pipeline. Please be aware, however, that the details - especially with respect to the page lifecycle and events - have changed significantly since the article was written. (thanks to John Saunders for calling that out in the comments) [Link]

• This question is another high level view of HttpHandlers [Link]