ASP.NET Request Life Cycle Events

ASP.NET Request Life Cycle Events: IIS Architecture को बेहतर तरीके से समझने के लिए जरूरी है कि हम किसी ASP.NET Application द्वारा Send की गई किसी HTTP Request के Flow को Step-by-Step समझें।

IIS Web Server पर जब भी कोई Request आता है, वह Request, Target Application के Application Pool में Queue हो जाता है। फिर Worker Process इस Application Pool से उस Request को Pick करता है और उसे Target Application पर Forward कर देता है। इसके बाद IIS Web Server पर इस Request के साथ क्या होता है, ये बात पूरी तरह से IIS 7 Pipeline Mode पर निर्भर करता है, जो कि Classic या Integrated में से कोई एक होता है।

जब IIS 7 का Pipeline Mode Classic होता है, तब IIS Web Server, IIS 6 की तरह काम करता है, जिसमें  दो भिन्न Runtime Environment होते हैं। जबकि Integrated Option Selected होने की स्थिति में IIS Server, IIS 7 की तरह काम करता है, जिसमें  एक ही Standard Runtime Environment होता है और हम यहां ये मान रहे हैं कि हमारा HTTP Request IIS 7 पर Flow हो रहा है। यानी IIS 7 के Application Pool का Pipeline Mode “Integrated” है।

जब IIS 7 पर कोई Request Processing के लिए Flow हो रहा होता है, तब वह कई Events के एक Event Chain से गुजरता है, जो कि Request Life Cycleके विभिन्न Events की तरह Represent होते हैं।

Request Life Cycle Events

IIS Messaging Pipeline के अन्तर्गत अग्रानुसार Described विभिन्‍न Events Trigger होते हैं और इन Events के Trigger होने के Response में Execute होने के लिए हम हमारे Custom Event Handlers Create कर सकते हैं जो कि TTP Modules के रूप में अथवा Global.asax File में लिखे गए Methods के रूप में हो सकते हैं।

किसी Request की Life Cycle में Trigger होने वाले विभिन्न Events की Sequence निम्नानुसार होती है:

• BeginRequest

इस Event के Fire होने पर ASP.NET HTTP Pipeline, Request Processing के लिए अपना काम शुरू करता है। किसी Application Instance के Lifetime में Send की जाने वाली First Request के लिए ये Event सम्बंधित Application में Application_Start() Method के बाद पहुंचता है।

• AuthenticateRequest

इस Event के Fire होने पर Request का Authentication होता है। इस Event के साथ ASP.NET व IIS Integrated Authentication Module इस Event के साथ Subscribe होते हैं और एक Identity Produce करते हैं।  यदि कोई Authentication Module कोई Authenticated User Produce नहीं करता है, तो एक Default Internal Authentication Module Invoke होता है और Unauthenticated User के लिए एक Identify Produce करता है। ऐसा Application की Consistency के लिए किया जाता है ताकि Code में Null Identifier की समस्या पैदा न हो।

• PostAuthenticateRequest

इस Event के Fire होने तक Request का Authentication हो चुका होता है और जो भी Information Available होती है, उसे HttpContext User Property में Store कर दिया जाता है।

• AuthorizeRequest

इस Event के Fire होने तक RequestAuthentication पूर्ण होने वाला होता है।इस Event को सामान्‍यत: Business Logic या अन्‍य Application Requirements के आधार पर Custom Authorization Perform करने के लिए Application Code द्वारा Handle किया जाता है।

• PostAuthorizeRequest

इस Event के Fire होने तक Request पूरी  तरह से Authorize हो चुका होता है।

• ResolveRequestCache

इस Event के Fire होने तक Runtime Environment इस बात को Verify करता है कि क्या पिछली Request के कारण जो Page Return किया गया था, उसे Current Request के लिए फिर से Return किया जा सकता है या नहीं। यदि Current Request को Fulfill करने के लिए Valid Cached Representation प्राप्त हो जाता है, तो Current Request को Cache से Serve कर दिया जाता है  तथा  Current Request को EndRequest Handler को Call करते हुए Short-Circuit करते कर दिया जाता है। ASP.NET Output Cache व IIS 7.0 का Output Cache, दोनों “Execute Now” Capabilities को Support करते हैं।

• PostResolveRequestCache

इस Event के Fire होने का मतलब है कि Request को Cache से Server नहीं किया जा सकता व Procedure इससे आगे Continue हो जाता है। इसी Point पर Requested URL से सम्बंधित एक नया HTTP Handler Create होता है। साथ ही यदि Requested Resource कोई .aspx Page हो, तो इसी Point पर Page Class का एक Instance Create होता है।

• MapRequestHandler

ये Event Request Handler को Determine करने के लिए Fire होता है।

• PostMapRequestHandler

ये Event तब Fire होता है, जब Requested URL से सम्बंधित HTTP Handler Successfully Create हो जाता है।

• AcquireRequestState

वह Module, जो इस Event के साथ Hook होता है, Request के लिए किसी State Information को Retrieve करने की कोशिश करता है। यहां कई Relevant Factors काम करते हैं, जिसके अन्तर्गत Handler को किसी न किसी रूप में Session State को Support करना होता है व इसी Point पर एक Valid Session ID होना भी जरूरी होता है।

• PostAcquiredRequestState

इस Event के Fire होने rd Application या Session से सम्बंधित State Information को Acquired किया जा चुका होता है  तथा  State Information से सम्बंधित Information को HttpContext से सम्बंधित Properties में इसी Point पर Store किया जाता है।

• PreRequestHandlerExecute

किसी Request को Handle करने हेतु Define किए गए Handler को Execute करने से Just पहले ये Event Fire होता है।

• ExecuteRequestHandler

Request Flow के इस Point पर Handler अपना काम पूरा करते हुए Client के लिए Output Generate करता है।

• PostRequestHandlerExecute

जब ये Event Fire होता है, तब Selected HTTP Handler पूरी तरह से Execute होकर Response Text Generate कर चुका होता है।

• ReleaseRequestState

ये Event तब Fire होता है, जब Handler अपनी State Information को Release करता है  तथा  Shut Down होने के लिए Prepare हो रहा होता है। इस Event को सामान्‍यत: Session State Module द्वारा यदि जरूरत हो तो Dirty Session State को Update करने के लिए Use किया जाता है। जब किसी Expired Session State वाले URL को Client द्वारा Execute किया जाता है, तो ASP.NET Platform उस समान Session ID के लिए ही फिर से उसी नाम का एक नया Session ID Create करता है। इसलिए इस प्रकार के Expired Session IDको Dirty Session ID के नाम से जाना जाता है।

• PostReleaseRequestState

इस Event के Trigger होने तक State को Page Execution द्वारा जैसा Modify किया जाता है, उसी को Persisted रखा जाता है।

• UpdateRequestCache

इस Event के Trigger होने rdRuntime Environmentbl बात को निश्चित करता है कि क्या Generate होने वाला Output विभिन्न Registered Modules द्वारा इस Point तक Properly Filter हो गया है या नहीं और क्या उसे समान प्रकार की Request आने पर बिना फिर से Process किए हुए Serve किए जाने के लिए Cache किया जा सकता है या नहीं।

• PostUpdateRequestCache

इस Event के Trigger होने तक यदि Save करने के लिए Configure किया गया हो, तो Generated Output को Output Cache में Save कर दिया जाता है।

• LogRequest

इस Event के Trigger होने का मतलब ये है कि Runtime Environment आने वाली Request के Result (Success/Failure) को Log File में Log करने के लिए तैयार है। Logging एक ऐसा Action है, जो Request के Fail या Success किसी भी स्थिति में जरूर Perform होता है व Request की Final Status को Represent करने के लिए Log File में Entry करता है।

• PostLogRequest

इस Event के Trigger होने तक Request की Status को Log File में Log कर दिया गया होता है।

• EndRequest

ये Event, Pipelineके Final Step की तरह Fire होता है। इस Point तक Web Browser को Send किए जाने के लिए Response उपलब्ध होता है जिसे उन अन्‍य Modules के लिए भी Available करवाया जा सकता है जो Compression या Encryption या किसी अन्‍य प्रकार के Manipulation Operation को उस Response Data पर Apply करना चाहते हैं।

इस Request Flow के अलावा PreSendRequestHeadersoPreSendRequestContent दो और Events भी Trigger हो सकते हैं, लेकिन उनके Trigger होने का क्रम निश्चित नहीं होता।

PreSendRequestHeaders Event, उस HttpApplication Object को Inform करता है जो उस Request को Handle करने के लिए Charge में होता है जिसके लिए HTTP Header को Send किया जाना है। जबकि PreSendRequestContent Event, उस HttpApplication Object को Inform करता है जो उस Request को Handle करने के लिए Charge में होता है जिसके लिए Response Bodyको Send किया जाना है।

सामान्‍यत: ये दोनों ही Events, EndRequest के Fire होने के बाद Fire होते हैं, लेकिन हमेंशा Fire होते ही हों, ये जरूरी नहीं है। उदाहरण के लिए यदि Buffering को Turned-Off किया गया हो, तो ये Event कुछ Content के Web Browser Client पर Sent होते ही Fire हो जाते हैं।

जबकि Error नाम का तीसरा Event भी एक Non-Deterministic Application Event है, जो केवल उसी स्थिति में Trigger होता है, जबकि Request Processing के Flow में किसी प्रकार का Error Generate हो।

तकनीकी रूप से देखा जाए तो लगभग ज्यादातर IIS Pipeline Events को ASP.NET HttpApplication Class के Events की तरह ही Exposed होते हैं। हालांकि ExecuteRequestHandler Event एक अपवाद है। इस Event को हम IIS Messaging Pipeline में प्राप्त करते हैं, लेकिन ASP.NET के अन्तर्गत इस Event को Subscribe करने का कोई Simple तरीका नहीं है।

Internally ASP.NET Runtime इस Event के साथ Notification प्राप्त करने के लिए उस समय Subscribe होता है, जब ASP.NET Request को Output Produce करना होता है। ऐसा तब होता है, जब हम ऐसे Unmanaged Codes Use कर रहे होते हैं, जो कि Developers के लिए Publicly Available नहीं होते।

यदि हम इस बात को Control करना चाहें कि एक Incoming Request IIS द्वारा किस प्रकार से Execute होगी, तो हमें Win32 ISAPI Filters को फिर से एक Option के रूप में Reuse करना पडता है। यदि हम इस बात को Control करना चाहें कि एक ASP.NET Request किस प्रकार से Execute होगी, तो हमें IIS केExecuteRequestHandler Event की जरूरत नहीं होती, क्योंकि Simple HTTP Handler ही इस जरूरत को पूरा कर देता है।

ASP.NET Request Processing in Integrated Pipeline Mode

Integrated Pipeline में कोई ASP.NET Request सामान्‍यत: किसी भी अन्‍य Request की तरह ही होता हैं। जब वह Application Pool जिसमें  ASP.NET Application Integrated Pipeline Mode में Run होने के लिए Initialize होता है, तो ये Worker Process को Applications ASP.NET में Host करता है और ASP.NET को IIS Pipeline Events के लिए विभिन्न प्रकार के Built-In HTTP Modules व Handlers को Register करने का Chance देता है। जो इस बात की Guarantee होता है कि Forms Authentication, Session State व Output Caching ठीक उसी प्रकार से काम करेंगे, जिस प्रकार से ASP.NET में करने चाहिए। साथ ही ASP.NET Runtime उस समय Notification प्राप्त करने के लिए भी Subscribe करता है, जब ASP.NET Request की Processing करने की जरूरत होती है।

PreRequestHandlerExecute व PostRequestHandlerExecute Events के बीच IIS, ASP.NET Runtime Environment Actual Processing करने के लिए ASP.NET Request को कुछ Code देता है।

साथ ही IIS Worker Processes में Hosted ASP.NET Environment को ApplicationManager नाम की एक नई Class द्वारा किया जाता है। ये Class समान Application Pool में Exist विभिन्न ASP.NET Applications को Normal तरीके से Run करने के लिए जरूरत के अनुसार AppDomains Create व Manage करता है।

Initialization के दौरान ApplicationManager Class एक Specific PipelineRuntime Object को Invoke करता है, जो कि अपने अन्तिम काम के रूप में ExecuteRequestHandler Event के लिए एक Handler को Register करता है।

फिर इस ASP.NET Internal Handler को IIS द्वारा उस समय फिर से Callback किया जाता है, जब ASP.NET Request को Process होने की जरूरत होती है। ये Handler HttpRuntime Object पर एक नया Static Method Invoke करता है, जो Request Notification के Trigger होने का ध्‍यान रखता है।

Invoke होने वाला Method उस HTTP Handler को Retrieve करता है, जो कि Request के Charge में होता है, Request के लिए HTTP Context को Prepare करता है व HTTP Handler के Public Interface को Invoke करता है। इस प्रक्रिया को हम निम्न चित्र के रूप में भी Represent कर सकते हैं:

Building Response for Request

प्रत्येक ASP.NET Request HTTP Handler नाम के एक Special Component के साथ Map होता है। जहां ASP.NET Runtime एक Internal Algorithm को Use करते हुए इस बात का पता लगाता है कि Current Request की Processing के लिए कौनसा HTTP Handler Charge में है।

Web Forms में ये Algorithm Request किए गए Webpage के URL पर आधारित होता है, जहां प्रत्येक Requested Page के लिए एक अलग HTTP Handler होता है। उदाहरण के लिए यदि User Default.aspx Page की Request करता है, तो इस Request को Handle करने के लिए ASP.Default_aspx नाम का HTTP Handler Class Create होता है, जो कि उस Code-Behind Class (Default.aspx.cs) से Inherit होता है, जिसे हम हमारे Source-Code में Define करते हैं।

जब Default.aspx Page के लिए पहली बार Request Perform करता है, तो उस समय तक ASP.Default_aspx Class AppDomain में Exist नहीं होती है और यदि ये Class Exist नहीं होती है, तो इस Class के लिए लिखे गए Source Codes को ASPX Markup की Parsing करते हुए Obtain किया जाता है और फिर इस Obtained Class Codes को Compile करके AppDomain की Memory में Directly Load कर दिया जाता है। फिर जब User इसी Default.aspx Page के लिए अगली बार Request Perform करता है, तो उस अगली Request के लिए ये पूरा Process फिर से Follow नहीं होता, बल्कि उस अगली Request को Fulfill करने के लिए AppDomain में Exist Instance को ही Use कर लिया जाता है।

हालांकि यदि Code-Behind File के Source Code में किसी प्रकार का कोई परिवर्तन किया गया हो, तो उस परिवर्तन के बाद Perform होने वाली First Request के लिए उपरोक्त सारे Steps फिर से Follow होते हैं, ताकि User को उस Page का Latest Updated Version ही प्राप्त हो।

HTTP Handler एक Managed Class होती है, जिसमें  IHttpHandler Interface को Implement किया गया होता है, जैसाकि निम्नानुसार Code Snippet में दर्शाया गया है:

publicinterfaceIHttpHandler

{

  void ProcessRequest(HttpContext context);

  bool IsReusable { get; }

}

WebForms Pages के लिए System.Web.UI.Page नाम की जो Base Class है, वह एक ऐसी ही Class है, जिसमें  IHttpHandler Interface को काफी बेहतर तरीके से Implement किया गया है। परिणामस्वरूप Page Class वास्तव में एक Page Controller Pattern के पूर्ण Implementation को Represent करता है।

System.Web.UI.Page Class काProcessRequest() Method Posted Data, View State व Server Controls को Client Web Browser के लिए Resultant HTML Markup Produce करने के लिए Use करता है। क्योंकि Page Class यही मानकर अपना काम करता है कि User ने किसी HTML Webpage के लिए ही Request Perform किया है और Output के रूप में User को HTML Markup ही Return करना है।

हालांकि किसी Individual Request हेतु अथवा Logically Define किए गए Group of Requests के लिए हम किसी Application में Alternative Handler Class Define कर सकते हैं, जो Resultant Response Generate करने के लिए Page Class के Logic के स्थान पर अलग तरह का Logic Use कर सकता है।

Alternative HTTP Handler को हम किसी Particular URL के साथ भी Map कर सकते हैं, जिसे Existing Server Resources को आवश्‍यक रूप से Point करना जरूरी नहीं होता और यही ASP.NET MVC में Routing के माध्‍यम से किया जाता है।

यानी ASP.NET WebForms URL Routing को Support करता है, जिसके अन्तर्गत हमें Incoming URL को किसी Specific ASPX Page के साथ Map या Bind करने की सुविधा प्राप्त होती है। हालांकि URLs की HTTP Handler Classes के साथ Mapping के लिए जो Standard Algorithm Define किया गया है, वह केवल तभी काम करता है, जबकि WebForms URL Routing को Use न किया गया हो।

Adding Own Code to Pipeline

जैसाकि हमने पिछले Section में बताया कि हम हमारी जरूरत के अनुसार किसी Request की Life Cycle के दौरान Trigger होने वाले विभिन्न Events के लिए स्वयं के Handlers भी Create कर सकते हैं और ऐसा करने के लिए हमें Managed HTTP Module Create करना होता है अथवा ge Global.asax File में भी अपने Managed Codes Add करते हुए Event Handler Methods Create कर सकते हैं, जो कि किसी Request के किसी Particular Event के Response में Execute होता है।

चलिए, समझने की कोशिश करते हैं कि हम किस प्रकार से अपने Application में किसी Request के Flow होते समय Trigger होने वाले विभिन्न प्रकार के Events के लिए Event Handler Methods Create कर सकते हैं, जो कि उन Particular Events के Trigger होने के Response में Execute हो जाते हैं, जबकि इन Event Handlers को हम हमारे Web Application की Global.asax File में कुछ निम्नानुसार तरीके से लिखते हैं:

protectedvoid Application_Start(object sender, EventArgs e)

{

  //Application Starting Point

}

यहां geus Application_EventName() Notation को Use किया है, जो कि Trigger होने वाले EventName के लिए एक Handler को Represent करता है। चूंकि Request Processing के दौरान Fire होने वाले विभिन्न Events, Request Level पर Fire होते हैं और Request हमेंशा किसी Particular Application के किसी Particular Resource के लिए होती है, इसलिए यहां Define किया जाने वाला Event Handler भी Application Level पर Fire होता है।

उदाहरण के लिए उपरोक्त Event Handler हमें ये सुविधा देता है कि जैसे ही हमारा Request हमारे Application पर Processing के लिए Start होता है, हम कुछ Extra Specific Tasks को Perform करने से सम्बंधित Program Logics को इस Event Handler Method की Body में लिख सकते हैं।

Managed HTTP Module एक ऐसी Class होती है, जिसमें IHttpModule Interface को Implement किया गया होता है, जिसके Startup Code में HTTP Module एक या एक से अधिक Events के लिए Event Handler की तरह Programmatically Register होता है। फिर हम इस Module को अपने Application के साथ Register करते हैं और प्रत्येक Application Request के लिए इनके Trigger होने का Wait करते हैं।

यहां ध्‍यान देने वाली बात ये है कि HTTP Module को मूलत: दो तरीकों से Register किया जा सकता है। पहले तरीके के अन्तर्गत हम हमारे Web Application  की Web.config नाम की Configuration File को Use करते हैं।

जबकि दूसरे तरीके के अन्तर्गत हम अपने IIS Web Server के IIS Manager Tool को Use करते हैं जो कि एक GUI Tool होता है और IIS के साथ ही हमारे Computer System पर Locally Install होता है। साथ ही URLs के साथ ASPX Pages की Mappings का समूह Directly IIS Manage के अन्दर ही ApplicationHost.config File में Store होता है।

IIS Manager में जब हम “Modules” Option को Select करते हैं और एक नया Module Add करने के लिए जब हम अगले चित्र में दर्शा, अनुसार “Add Managed Module…” Option पर Click करते हैं, तो हमारे सामने एक नया Dialog Box Display होता है, जिसमें  हमें हमारे एक Module का एक Unique नाम व Type Specify करना होता है।

कोई HTTP Module, ASP.NET Managed व Native दोनों प्रकार की Requests को Operate कर सकता है। जहां Native Request एक ऐसी Request होती है, जिसे Flow होने के लिए ASP.NET Runtime Environment की जरूरत नहीं होती। इसके अन्तर्गत सामान्‍यत: जब कोई JPEG Image या Static HTML Page Serve किया जाना होता है, तब Web Server पर आने वाली Incoming Request एक प्रकार की Native Request होती है।