|
| handling a request in asp.net |
|
|
|
|
| Messages |
|
Related Types |
This message was discovered on microsoft.public.dotnet.framework.aspnet.
| Can Balioglu |
I'm trying to figure out how asp.net processes a request. This is what I
understand from the .net documentation. Can you just check if I'm right?
When a request comes to the iis server aspnet_isapi.dll forwards the request
to the aspnet_wp.exe. Asp.net worker process has a pool of HttpApplication
objects in memory. The request is assigned to an HttpApplication instance.
HttpApplication object raises several events while processing the request.
After ResolveRequestCache event a HttpHandler instance is created. (Which is
most of the time a Page instance for an .aspx file) And a HttpContext object
which is generated by asp.net is passed as an argument to this handler.
After the handler finishes its work using ProcessRequest method (for
synchronous handlers). The remaining cleanup events are raised by the
HttpApplication instance and at the end, after the request is completely
processed, HttpApplication instance gets back to the pool for waiting a new
request.
Is this correct?
And I have two questions. Why does the HttpApplication class inherits
IHttpHandler interface? HttpApplication handles every request anyway.
Which event causes the Application_Start and _End methods in a global.asax
file to run? HttpApplication does only have events related to request
processing.
|
|
|
| |
|
| |
| |
| John Allen (ms) |
Good questions your pretty close. I'll see if I can answer all of your
questions and go into a bit more detail. Here's the answers to your
questions:
1) Which event causes the Application_Start and _End methods in a
global.asax file to run? HttpApplication does only have events related to
request processing.
The Application_Start and Application_End methods are not technically
Application level events. The Application_Start method is fired when the
very first HttpApplication object of the web application is initialized.
The Application_End method is executed when the Web application is shutdown
(modification to web.config, global.asax, bin directory modification...).
After all the HttpApplication instances have been shutdown, the Dispose()
method of the HttpApplicationFactory should be called. This is when we
call the Application_End method if you've wired one up.
2) Why does the HttpApplication class inherits IHttpHandler interface?
HttpApplication handles every request anyway.
This is a very good question. I thought about this a while back and found
that there's really not much to it. It's just a coincidence that the
HttpApplication is an async handler. The responsiblity of the
HttpApplication is to execute the module "pipeline" and to call the "real"
Http Handler as you'll see down below.
Below is just to clarify in a bit more detail what happens to a request
when we hand it off to the asp.net worker process:
1. When a request comes into the asp.net worker process, based on the web
application requested, we retrieve an instance of an HttpApplication object
from a pool of HttpApplication objects. If no HttpApplication objects have
been instantiated or none are available in the pool, then we'll go ahead
and initialize a new one (this is where we wire up the HttpModule methods
to the HttpApplication level events). If it is the first HttpApplication
instance for the Web application then we'll fire the Application_Start
method.
2. Once we've got an HttpApplication instance to process a request, we go
through a predefined sequence of steps that was setup when we initialized
the HttpApplication in order to process the request. I'm not sure how
clear the docs are on how this actually works. But from a high level, we
execute our HttpModules, then we execute our HttpHandler, then we go back
through our HttpModules, like a "pipeline". Hopefully below will give you
a bit more insight as to what is happening at the low level.
Below is the execution sequece for an .aspx page with all the default
configuration settings and with the BeginRequest, EndRequest &
AuthenticateRequest events wired up in your global.asa(hopefully this table
is formatted for everyone else, sorry if its not):
Application Event ModuleMethod
Module/Object
============================================================================
====
BeginRequest 1) Application_BeginRequest()
global.asa
AuthenticateRequest 2) OnEnter()
WindowsAuthentication
AuthenticateRequest 3) OnEnter()
FormsAuthentication
AuthenticateRequest 4) OnEnter()
PassportAuthentication
AuthenticateRequest 5)
Application_AuthenticateRequest() global.asa
AuthenticateRequest 6) OnEnter()
*internal
AuthorizeRequest 7) OnEnter()
UrlAuthorization
AuthorizeRequest 8) OnEnter()
FileAuthorization
ResolveRequestCache 9) OnEnter()
OutputCache
*none 10) MapHttpHandler()
PageHandlerFactory
AcquireRequestState 11) BeginAcquireState()
SessionState
*none 12) ProcessRequest()
Page(IHttpHandler)
ReleaseRequestState 13) OnReleaseState()
SessionState
*none 14) FilterOutput()
*internal
UpdateRequestCache 15) OnLeave()
OutputCache
EndRequest 16) OnEndRequest()
SessionState
EndRequest 17) OnLeave()
FormsAuthentication
EndRequest 18) OnLeave()
PassportAuthentication
EndRequest 19) Application_EndRequest()
global.asa
I want to point out a couple of important steps in the sequence. Step 10
is where we check the file extension of the page being requested and then
grab the appropriate HttpHandler to process the request. In the case of a
.aspx page, it will return the type of your page (this is because all your
.aspx pages implicitly implement the IHttpHandler interface). Steps 12 is
where we actaully call the ProcessRequest() method of your page (it
actually calls the Page classes implementation of ProcessRequest).
Another important note in regards to the order in which methods which are
wired up to the same HttpApplication level event are executed: Take the
EndRequest event for example. It has 4 methods wired up to it. The order
in which these will execute is as follows:
1. The order in which the HttpModules are added in the
web.config. HttpModules added first will be executed first.
2. Corresponding event in the global.asax
3. After this execution sequence is complete, we send the HttpApplication
instance back to the pool so that it can be used to process other requests.
HTH, John
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. © 2001 Microsoft Corporation. All rights
reserved.
|
|
|
| |
|
| |
| |
| Can Balioglu |
Thank you very much for your answer. It was very helpfull.
|
|
|
| |
|
|
| |
|
|
|
|
|
|
|
|
|
BootFX
Reliable and powerful .NET application framework. |
|
|
|
|
|
|
