You are on page 1of 5

Introduction

This article describes the life cycle of the page from the moment the URL is hit from the
web browser till the HTML code is generated and sent to the web browser. Let us start
by looking at some keywords that are involved in the life cycle of the page.

Background

IIS: IIS (Internet Information Server) is a complete Web server that makes it possible
to quickly and easily deploy powerful Web sites and applications. It is the default web
server used with .NET. When a Web server (for ASP.NET applications, typically IIS)
receives a request, it examines the file-name extension of the requested file, determines
which ISAPI extension should handle the request, and then passes the request to the
appropriate ISAPI extension. (By default, ASP.NET handles file name extensions that
have been mapped to it, such as .aspx, .ascx, .ashx, and .asmx.)

Note:

a. If a file name extension has not been mapped to ASP.NET, ASP.NET will not
receive the request. It will be handled by the IIS. The requested page/image/file
is returned without any processing.
b. If you create a custom handler to service a particular file name extension, you
must map the extension to ASP.NET in IIS and also register the handler in your
application's Web.config file.

ASPNET_ISAPI.DLL: This DLL is the ISAPI extension provided with ASP.NET to process
the web page requests. IIS loads this DLL and sends the page request to this DLL. This
DLL loads the HTTPRuntime for further processing.

ASPNET_WP.EXE: Each worker process (ASPNET_WP.EXE) contains an Application


Pool. Each Application Pool can contain any number of Applications. Application Pool is
also called as AppDomain. When a web page is requested, IIS looks for the application
pool under which the current application is running and forwards the request to the
respective worker process.

HTTP Pipeline: HTTP Pipeline is the general-purpose framework for server-side HTTP
programming that serves as the foundation for ASP.NET pages as well as Web Services.
All the stages involved from creating HTTP Runtime to HTTP Handler is called HTTP
Pipeline.

HTTP Runtime: Each AppDomain has its own instance of the HttpRuntime class—the
entry point in the pipeline. The HttpRuntime object initializes a number of internal
objects that will help carry the request out. The HttpRuntime creates the context for
the request and fills it up with any HTTP information specific to the request. The context
is represented by an instance of the HttpContext class. Another helper object that
gets created at such an early stage of the HTTP runtime setup is the text writer—to
contain the response text for the browser. The text writer is an instance of the
HttpWriter class and is the object that actually buffers any text programmatically sent
out by the code in the page. Once the HTTP runtime is initialized, it finds an application
object to fulfill the request. The HttpRuntime object examines the request and figures
out which application it was sent to (from the pipeline's perspective, a virtual directory is
an application).

HTTP Context: This is created by HTTP Runtime. The HttpContext class contains
objects that are specific to the current page request, such as the HttpRequest and
HttpResponse objects. You can use this class to share information between pages. It
can be accessed with Page.Context property in the code.

HTTP Request: Provides access to the current page request, including the request
headers, cookies, client certificate, query string, and so on. You can use this class to
read what the browser has sent. It can be accessed with Page.Request property in the
code.

HTTP Response: Provides access to the output stream for the current page. You can
use this class to inject text into the page, to write cookies, and more. It can be accessed
with Page.Response property in the code.

HTTP Application: An application object is an instance of the HttpApplication


class—the class behind the global.asax file. HTTPRuntime uses
HttpApplicationFactory to create the HTTPApplication object. The main task
accomplished by the HTTP application manager is finding out the class that will actually
handle the request. When the request is for an .aspx resource, the handler is a page
handler—namely, an instance of a class that inherits from Page. The association
between types of resources and types of handlers is stored in the configuration file of the
application. More exactly, the default set of mappings is defined in the <httpHandlers>
section of the machine.config file. However, the application can customize the list of its
own HTTP handlers in the local web.config file. The line below illustrates the code that
defines the HTTP handler for .aspx resources.

Collapse Copy Code


<add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory"/>

HttpApplicationFactory: Its main task consists of using the URL information to find a
match between the virtual directory of the URL and a pooled HttpApplication object.

HTTP Module: An HTTP module is an assembly that is called on every request that is
made to your application. HTTP modules are called as part of the ASP.NET request
pipeline and have access to life-cycle events throughout the request. HTTP modules let
you examine incoming and outgoing requests and take action based on the request.
They also let you examine the outgoing response and modify it. ASP.NET uses modules
to implement various application features, which include forms authentication, caching,
session state, and client script services. In each case, when those services are enabled,
the module is called as part of a request and performs tasks that are outside the scope
of any single page request. Modules can consume application events and can raise
events that can be handled in the Global.asax file.
HTTP Handler: An ASP.NET HTTP handler is the process that runs in response to a
request that is made to an ASP.NET Web application. The most common handler is an
ASP.NET page handler that processes .aspx files. When users request a .aspx file, the
request is processed by the page handler. We can write our own handler and handler
factory if we want to handle the page request in a different manner.

Note: HTTP modules differ from HTTP handlers. An HTTP handler returns a response to a
request that is identified by a file name extension or family of file name extensions. In
contrast, an HTTP module is invoked for all requests and responses. It subscribes to
event notifications in the request pipeline and lets you run code in registered event
handlers. The tasks that a module is used for are general to an application and to all
requests for resources in the application.

Life Cycle of Page

1. Web page request comes from browser.


2. IIS maps the ASP.NET file extensions to ASPNET_ISAPI.DLL, an ISAPI extension
provided with ASP.NET.
3. ASPNET_ISAPI.DLL forwards the request to the ASP.NET worker process
(ASPNET_WP.EXE or W3P.EXE).
4. ISAPI loads HTTPRuntime and passes the request to it. Thus, HTTP Pipelining has
begun.
5. HTTPRuntime uses HttpApplicationFactory to either create or reuse the
HTTPApplication object.
6. HTTPRuntime creates HTTPContext for the current request. HTTPContext
internally maintains HTTPRequest and HTTPResponse.
7. HTTPRuntime also maps the HTTPContext to the HTTPApplication which
handles the application level events.
8. HTTPApplication runs the HTTPModules for the page requests.
9. HTTPApplication creates HTTPHandler for the page request. This is the last
stage of HTTPipelining.
10. HTTPHandlers are responsible to process request and generate corresponding
response messages.
11. Once the request leaves the HTTPPipeline, page level events begin.
12. Page Events are as follows: PreInit, Init, InitComplete, PreLoad, Load,
Control events (Postback events), Load Complete, PreRender,
SaveStateComplete, Render and Unload.
13. HTTPHandler generates the response with the above events and sends back to
the IIS which in turn sends the response to the client browser.
Events in the Life Cycle of Page

PreInit: All the Pre and Post events are introduced as part of .NET Framework 2.0. As
the name suggests, this event is fired before the Init method is fired. Most common
functionalities implemented in this method include:

a. Check the IsPostBack property


b. Set the master page dynamically
c. Set the theme property of the page dynamically
d. Read or Set the profile property values
e. Re-create the dynamic controls

Init: This event is raised after all controls in the page are initialized and any skin
settings have been applied. This event is used to read or initialize control properties. It
can be used to register events for some controls for which the events are not specified in
the aspx page.
Ex: OnClick event of the Button can be registered in the Init rather than specifying
in the OnClick property of the Button in the aspx page.

InitComplete: Use this event for processing tasks that require all initialization to be
complete.

PreLoad: Use this event if you need to perform processing on your page or control
before the Load event. After the Page raises this event, it loads view state for itself
and all controls, and then processes any postback data included with the Request
instance.

Load: The Page calls the OnLoad event method on the Page, then recursively does the
same for each child control, which does the same for each of its child controls until the
page and all controls are loaded. Use the OnLoad event method to set properties in
controls and establish database connections.

Control events: Use these events to handle specific control events, such as a Button
control's Click event or a TextBox control's TextChanged event.

LoadComplete: Use this event for tasks that require that all other controls on the page
be loaded.

PreRender: This is the last event raised before the HTML code is generated for the
page. The PreRender event also occurs for each control on the page. Use the event to
make final changes to the contents of the page or its controls.

SaveStateComplete: Before this event occurs, ViewState has been saved for the
page and for all controls. Any changes to the page or controls at this point will be
ignored.
Use this event to perform tasks that require view state to be saved, but that do not
make any changes to controls.

Render: This is the stage where the HTML code for the page is rendered. The Page
object calls the Render method of each control at this stage. All ASP.NET Web server
controls have a Render method that writes out the control's markup that is sent to the
browser.

UnLoad: This event occurs for each control and then for the page. In controls, use this
event to do final cleanup for specific controls, such as closing control-specific database
connections.
For the page itself, use this event to do final cleanup work, such as closing open files and
database connections, or finishing up logging or other request-specific tasks.

You might also like