Step 1: The browser sends a request to IIS. IIS first
checks which ISAPI extension can serve this request. Depending on file
extension the request is processed. For instance, if the page is an ‘.ASPX
page’, then it will be passed to ‘aspnet_isapi.dll’ for processing.
Step 2: If this is the first request to the website, then a class called as ‘ApplicationManager’ creates an application domain where the website can run. As we all know, the application domain creates isolation between two web applications hosted on the same IIS. So in case there is an issue in one app domain, it does not affect the other app domain.
Step 3: The newly created application domain creates hosting environment, i.e. the ‘HttpRuntime’ object. Once the hosting environment is created, the necessary core ASP.NET objects like ‘HttpContext’ , ‘HttpRequest’ and ‘HttpResponse’ objects are created.
Step 4: Once all the core ASP.NET objects are created, ‘HttpApplication’ object is created to serve the request. In case you have a ‘global.asax’ file in your system, then the object of the ‘global.asax’ file will be created. Please note global.asax file inherits from ‘HttpApplication’ class.
Note: The first time an ASP.NET page is attached to an application, a new instance of ‘HttpApplication’ is created. Said and done to maximize performance, HttpApplication instances might be reused for multiple requests.
Step 5: The HttpApplication object is then assigned to the core ASP.NET objects to process the page.
Step 6: HttpApplication then starts processing the request by HTTP module events, handlers and page events. It fires the MHPM event for request processing.
Note: For more details.
Step 2: If this is the first request to the website, then a class called as ‘ApplicationManager’ creates an application domain where the website can run. As we all know, the application domain creates isolation between two web applications hosted on the same IIS. So in case there is an issue in one app domain, it does not affect the other app domain.
Step 3: The newly created application domain creates hosting environment, i.e. the ‘HttpRuntime’ object. Once the hosting environment is created, the necessary core ASP.NET objects like ‘HttpContext’ , ‘HttpRequest’ and ‘HttpResponse’ objects are created.
Step 4: Once all the core ASP.NET objects are created, ‘HttpApplication’ object is created to serve the request. In case you have a ‘global.asax’ file in your system, then the object of the ‘global.asax’ file will be created. Please note global.asax file inherits from ‘HttpApplication’ class.
Note: The first time an ASP.NET page is attached to an application, a new instance of ‘HttpApplication’ is created. Said and done to maximize performance, HttpApplication instances might be reused for multiple requests.
Step 5: The HttpApplication object is then assigned to the core ASP.NET objects to process the page.
Step 6: HttpApplication then starts processing the request by HTTP module events, handlers and page events. It fires the MHPM event for request processing.
Note: For more details.
The Global.asax file, which is derived from the
HttpApplication class, maintains a pool of HttpApplication objects, and assigns
them to applications as needed. The Global.asax file contains the following
events:
Application_Init: Fired when an application initializes or
is first called. It's invoked for all HttpApplication object instances.
Application_Disposed: Fired just before an application is
destroyed. This is the ideal location for cleaning up previously used
resources.
Application_Error: Fired when an unhandled exception is
encountered within the application.
Application_Start: Fired when the first instance of the
HttpApplication class is created. It allows you to
create objects that are
accessible by all HttpApplication instances.
Application_End: Fired when the last instance of an
HttpApplication class is destroyed. It's fired only once during an
application's lifetime.
Application_BeginRequest: Fired when an application request
is received. It's the first event fired for a request, which is often a page
request (URL) that a user enters.
Application_EndRequest: The last event fired for an
application request.
Application_PreRequestHandlerExecute: Fired before the
ASP.NET page framework begins executing an event handler like a page or Web
service.
Application_PostRequestHandlerExecute: Fired when the
ASP.NET page framework is finished executing an event handler.
Applcation_PreSendRequestHeaders: Fired before the ASP.NET
page framework sends HTTP headers to a requesting client (browser).
Application_PreSendContent: Fired before the ASP.NET page
framework sends content to a requesting client (browser).
Application_AcquireRequestState: Fired when the ASP.NET page
framework gets the current state (Session state) related to the current
request.
Application_ReleaseRequestState: Fired when the ASP.NET page
framework completes execution of all event handlers. This results in all state
modules to save their current state data.
Application_ResolveRequestCache: Fired when the ASP.NET page
framework completes an authorization request. It allows caching modules to
serve the request from the cache, thus bypassing handler execution.
Application_UpdateRequestCache: Fired when the ASP.NET page framework
completes handler execution to allow caching modules to store responses to be
used to handle subsequent requests.
Application_AuthenticateRequest: Fired when the security
module has established the current user's identity as valid. At this point, the
user's credentials have been validated.
Application_AuthorizeRequest: Fired when the security module
has verified that a user can access resources.
Session_Start: Fired when a new user visits the application
Web site.
Session_End: Fired when a user's session times out, ends, or
they leave the application Web site.
The event list may seem daunting, but it can be useful in
various circumstances.
A key issue with taking advantage of the events is knowing
the order in which they're triggered. The Application_Init and
Application_Start events are fired once when the application is first started.
Likewise, the Application_Disposed and Application_End are only fired once when
the application terminates. In addition, the session-based events
(Session_Start and Session_End) are only used when users enter and leave the
site. The remaining events deal with application requests, and they're
triggered in the following order:
Application_BeginRequest
Application_AuthenticateRequest
Application_AuthorizeRequest
Application_ResolveRequestCache
Application_AcquireRequestState
Application_PreRequestHandlerExecute
Application_PreSendRequestHeaders
Application_PreSendRequestContent
protected void Page_init(object sender, EventArgs e)
{
clsHttpModule.objArrayList.Add("Page:Init");
}
protected void Page_Load(object sender, EventArgs e)
{
clsHttpModule.objArrayList.Add("Page:Load");
}
public override void Validate()
{
clsHttpModule.objArrayList.Add("Page:Validate");
}
protected void Button1_Click(object sender, EventArgs e)
{
clsHttpModule.objArrayList.Add("Page:Event");
}
protected override void Render(HtmlTextWriter output)
{
clsHttpModule.objArrayList.Add("Page:Render");
base.Render(output);
}
protected void Page_Unload(object sender, EventArgs e)
{
clsHttpModule.objArrayList.Add("Page:UnLoad");
}}
Application_PostRequestHandlerExecute
Application_ReleaseRequestState
Application_UpdateRequestCache
Application_EndRequest
A common use of some of these events is security. The
following C# example demonstrates various Global.asax events with the Application
Authenticate event used to facilitate forms-based authentication via a cookie.
In addition, the Application_Start event populates an application variable,
while Session_Start populates a session variable. The Application_Error event
displays a simple message stating an error has occurred.
No comments:
Post a Comment