An ASP.NET HTTP handler is the process (frequently referred to as the "endpoint"), responsible for generating response against an extension mapped in IIS.
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.
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.
An HTTP module is an assembly that is called on every request that is made to your application.
Modules must be registered to receive notifications from the request pipeline.
You can implement much of the functionality of a module in the application's Global.asax file, which enables you to respond to application events. However, modules have an advantage over the Global.asax file because they are encapsulated and can be created one time and used in many different applications
In IIS 6.0, the ASP.NET request pipeline is separate from the Web server request pipeline. In IIS 7.0, the ASP.NET request pipeline and the Web server request pipeline can be integrated into a common request pipeline. In IIS 7.0, this is referred to as Integrated mode. The unified pipeline has several benefits for ASP.NET developers. For example, it lets managed-code modules receive pipeline notifications for all requests, even if the requests are not for ASP.NET resources.
Global.asax is dynamically compiled the first time any page is requested, even before the target page is compiled.
Request > IIS 5.0 > aspnet_isapi > worker process (aspnet_wp.exe) > CLR > asp.net runtime
Request > IIS 6.0 > http.sys > app pool queue > worker process w3p.exe > aspnet_isapi > CLR > runtime
Any request coming to IIS is mapped to external module for processing, for e.x. request for asp.net is mapped to module called aspnet_isapi.dll.
There are resources which IIS directly serves like HTML pages,images or Kernel cached pages. Kernel cached pages are pages which are configured for page output caching in asp.net.
aspnet_isapi: Any module which can handle web resources in the context of IIS are ISAPI extensions/module (Internet server application programming interface)., these are plain win32 dll which implement predefined interfaces which is also well known to IIS, so at any time to accomplish any task, IIS can load these dlls and call appropriate functions. For asp.net request this extension or module is aspnet_isapi .
IIS 5.0 model: In this model aspnet_isapi.dll act as dispatcher, it evaluates the request and routes the request towards another process - ASP.net worker process aspnet_wp.exe, which actually loads CLR and starts asp.net runtime to process the request.
The communication b/w aspnet_isapi.dll and aspnet_wp.exe take place through named pipes which is costly.
There is only one worker process for all active web applications, each running in distinct Appdomain.
If a web sever has multiple CPUs than it can be configured to have diff worker process for different CPU, this is know as web garden and is controlled by attributessection in machine.config file.
IIS 6.0 Process Model: In this model a new concept of applicaiton pool and http.sys is introduced. this model also know as "worker process isolation mode".
Application pool is a group of web applicaitons that share same copy of worker process or share same security settings. this is a way of seperating differnt application to avoid impact of malfunctioning in one app to other.
http.sys is a kernel-mode device driver which act as a dispatcher. It evaluate the request and routes it to the queue managed by application pool that the invoked application belongs to.
There is one queue per application pool, woker process of app pool in IIS 6.0 is called w3wp.exe which runs under NETWORK SERVICE account. w3wp.exe monitors the queue and loads aspnet_isapi.dll, which in turn load CLR and start asp.net pipeline to process the request. so since the communication b/w worker process and aspnet_isapi is in same process so it's cheaper.
Once the CLR loaded HttpPipeline is initialized to service the request. The ultimate goal of the pipeline is finding in the current Appdomain , a managed class that fully represent requested ASP.net resource to convert request into markup which can be rendered on browser. Http pipline is a fully extensible chain of managed objects.
Following are the main components of the pipeline.
1. HttpRuntime.
2. HttpApplicationFactory
3. HttpApplication.
4. HttpModules
5. PageHandlerFactory.
6. IHttpHandler.
All these objects form what is ofter refered as Asp.net Http Runtime Environment.
HttpRunTime
Entry point of Http pipeline is HttpRuntime, worker process of the corresponding Appdomain, activates Http pipeline by creating a new instance of HttpRuntime class and then calling it's processRequest method. Each web application/appdomain has its own copy of HttpRuntime (single instance i guess as process request is static).
Runtime creates many helper object to process request main are cache manager and file system monitor use to detect changes in application files. then it creates new http Context object for the request which encapsulates http specific information about the request and can be read/write along the pipeline. runtime creates specialized text writer which will hold the markup code. Now from context info runtime request HttpApplication factory to either locate or create applicaiton object capable of handling the request. application is searched using the virtual directory information contained int he URL.
HttpRuntime has following public methods:
1. Close - Removes all asp.net cache, and terminates the web application. Use this only if you implement you own hosting environment.
2. UnloadAppdomain: Terminates the current asp.net application. App restarts next time a request is received for it. This can be use if you reliazed your application needs to re-start.(there are many scenario will be discussed later).
3. ProcessRequest: All asp.net web processing logic.
Http Application Factory
During the lifetime of the applicaiton, Factory maintains a pool of Http Applicaiton object to server the incoming http request. pool is required b'coz each http application instance is used to process a single page request at time.
If no applicatin object is available in the pool it creates one by compiling the Global.asax if exit else base httapplication class is used and then compiling the assembly that represents the actual page request.
Http Appliction
It represent a running asp.net application. An instance of it is responsible to manage the entire lifetime of the request. It also maintains a list of registerd modules that are called during various moments of the elaboration of the request passes thru the pipeline
HttpApplicaitn object determines the type of object that represent the resource being requested, it can be a asp.net page, webservice or a usercontrol etc.then it delegates the type specific handler factory to return the instance of that type. Handler factory returns a instance of managed class that can handle given Http request - this instance we called as Http Handlers. Ape.net page is an example of handler object. that is, an instance of class that implements IhhtpHandler interface.
Handler Factory
Http application dertermines the type of object require to handle the request and delegate the type specific handler factory to create an instance of the type. Application identifies the type of handler from thesection of the configuration file for ex. for *.aspx extension PageHandlerFactory is required while for *.asmx extension WebServiceHandlerFactory is required.
Handler factory creates an instance of the object which represent the resource requested by the runtime. This object must implements IHttpHandler interface becoz once this object reach to runTime, runTime calls the ProcessRequest method of IHttpHandler interface which execute the user defined code and generate the markup for the browser.
http://stackoverflow.com/questions/716049/what-is-the-difference-between-classic-and-integrated-pipeline-mode-in-iis7:
IIS Pipline > managed pipelne. in Integrated both are unified.
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.
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.
An HTTP module is an assembly that is called on every request that is made to your application.
Modules must be registered to receive notifications from the request pipeline.
You can implement much of the functionality of a module in the application's Global.asax file, which enables you to respond to application events. However, modules have an advantage over the Global.asax file because they are encapsulated and can be created one time and used in many different applications
In IIS 6.0, the ASP.NET request pipeline is separate from the Web server request pipeline. In IIS 7.0, the ASP.NET request pipeline and the Web server request pipeline can be integrated into a common request pipeline. In IIS 7.0, this is referred to as Integrated mode. The unified pipeline has several benefits for ASP.NET developers. For example, it lets managed-code modules receive pipeline notifications for all requests, even if the requests are not for ASP.NET resources.
Global.asax is dynamically compiled the first time any page is requested, even before the target page is compiled.
Request > IIS 5.0 > aspnet_isapi > worker process (aspnet_wp.exe) > CLR > asp.net runtime
Request > IIS 6.0 > http.sys > app pool queue > worker process w3p.exe > aspnet_isapi > CLR > runtime
Any request coming to IIS is mapped to external module for processing, for e.x. request for asp.net is mapped to module called aspnet_isapi.dll.
There are resources which IIS directly serves like HTML pages,images or Kernel cached pages. Kernel cached pages are pages which are configured for page output caching in asp.net.
aspnet_isapi: Any module which can handle web resources in the context of IIS are ISAPI extensions/module (Internet server application programming interface)., these are plain win32 dll which implement predefined interfaces which is also well known to IIS, so at any time to accomplish any task, IIS can load these dlls and call appropriate functions. For asp.net request this extension or module is aspnet_isapi .
IIS 5.0 model: In this model aspnet_isapi.dll act as dispatcher, it evaluates the request and routes the request towards another process - ASP.net worker process aspnet_wp.exe, which actually loads CLR and starts asp.net runtime to process the request.
The communication b/w aspnet_isapi.dll and aspnet_wp.exe take place through named pipes which is costly.
There is only one worker process for all active web applications, each running in distinct Appdomain.
If a web sever has multiple CPUs than it can be configured to have diff worker process for different CPU, this is know as web garden and is controlled by attributes
IIS 6.0 Process Model: In this model a new concept of applicaiton pool and http.sys is introduced. this model also know as "worker process isolation mode".
Application pool is a group of web applicaitons that share same copy of worker process or share same security settings. this is a way of seperating differnt application to avoid impact of malfunctioning in one app to other.
http.sys is a kernel-mode device driver which act as a dispatcher. It evaluate the request and routes it to the queue managed by application pool that the invoked application belongs to.
There is one queue per application pool, woker process of app pool in IIS 6.0 is called w3wp.exe which runs under NETWORK SERVICE account. w3wp.exe monitors the queue and loads aspnet_isapi.dll, which in turn load CLR and start asp.net pipeline to process the request. so since the communication b/w worker process and aspnet_isapi is in same process so it's cheaper.
Once the CLR loaded HttpPipeline is initialized to service the request. The ultimate goal of the pipeline is finding in the current Appdomain , a managed class that fully represent requested ASP.net resource to convert request into markup which can be rendered on browser. Http pipline is a fully extensible chain of managed objects.
Following are the main components of the pipeline.
1. HttpRuntime.
2. HttpApplicationFactory
3. HttpApplication.
4. HttpModules
5. PageHandlerFactory.
6. IHttpHandler.
All these objects form what is ofter refered as Asp.net Http Runtime Environment.
HttpRunTime
Entry point of Http pipeline is HttpRuntime, worker process of the corresponding Appdomain, activates Http pipeline by creating a new instance of HttpRuntime class and then calling it's processRequest method. Each web application/appdomain has its own copy of HttpRuntime (single instance i guess as process request is static).
Runtime creates many helper object to process request main are cache manager and file system monitor use to detect changes in application files. then it creates new http Context object for the request which encapsulates http specific information about the request and can be read/write along the pipeline. runtime creates specialized text writer which will hold the markup code. Now from context info runtime request HttpApplication factory to either locate or create applicaiton object capable of handling the request. application is searched using the virtual directory information contained int he URL.
HttpRuntime has following public methods:
1. Close - Removes all asp.net cache, and terminates the web application. Use this only if you implement you own hosting environment.
2. UnloadAppdomain: Terminates the current asp.net application. App restarts next time a request is received for it. This can be use if you reliazed your application needs to re-start.(there are many scenario will be discussed later).
3. ProcessRequest: All asp.net web processing logic.
Http Application Factory
During the lifetime of the applicaiton, Factory maintains a pool of Http Applicaiton object to server the incoming http request. pool is required b'coz each http application instance is used to process a single page request at time.
If no applicatin object is available in the pool it creates one by compiling the Global.asax if exit else base httapplication class is used and then compiling the assembly that represents the actual page request.
Http Appliction
It represent a running asp.net application. An instance of it is responsible to manage the entire lifetime of the request. It also maintains a list of registerd modules that are called during various moments of the elaboration of the request passes thru the pipeline
HttpApplicaitn object determines the type of object that represent the resource being requested, it can be a asp.net page, webservice or a usercontrol etc.then it delegates the type specific handler factory to return the instance of that type. Handler factory returns a instance of managed class that can handle given Http request - this instance we called as Http Handlers. Ape.net page is an example of handler object. that is, an instance of class that implements IhhtpHandler interface.
Handler Factory
Http application dertermines the type of object require to handle the request and delegate the type specific handler factory to create an instance of the type. Application identifies the type of handler from the
Handler factory creates an instance of the object which represent the resource requested by the runtime. This object must implements IHttpHandler interface becoz once this object reach to runTime, runTime calls the ProcessRequest method of IHttpHandler interface which execute the user defined code and generate the markup for the browser.
Classic mode (the only mode in IIS6 and below) is a mode where IIS only works with ISAPI extensions and ISAPI filters directly. In fact, in this mode, ASP.NET is just an ISAPI extension (aspnet_isapi.dll) and an ISAPI filter (aspnet_filter.dll). IIS just treats ASP.NET as an external plugin implemented in ISAPI and works with it like a black box (and only when it's needs to give out the request to ASP.NET). In this mode, ASP.NET is not much different from PHP or other technologies for IIS.
Integrated mode, on the other hand, is a new mode in IIS7 where IIS pipeline is tightly integrated (i.e. is just the same) as ASP.NET request pipeline. ASP.NET can see every request it wants to and manipulate things along the way. ASP.NET is no longer treated as an external plugin. It's completely blended and integrated in IIS. In this mode, ASP.NET
HttpModules basically have nearly as much power as an ISAPI filter would have had and ASP.NET HttpHandlers can have nearly equivalent capability as an ISAPI extension could have. In this mode, ASP.NET is basically a part of IIS.
Very useful for URL re-writing which was not possible without integrated mode.
--------------------------
--------------------------
ASP.net
Thursday, October 10, 2013
10:27 AM
Worker
Process
Now,
HTTP.SYS is Responsible for pass the request to particular Application
pool. Now here is one question, How HTTP.SYS comes to
know where to send the request? This is not
a random pickup.
Whenever we creates a new Application Pool, the ID of the Application Pool is
being generated and it’s registered with the HTTP.SYS. So whenever HTTP.SYS
Received the request from any web application, it checks for the Application
Pool and based on the application pool it send the request.
Pasted from <http://abhijitjana.net/2010/03/14/beginner%e2%80%99s-guide-how-iis-process-asp-net-request/>
ASP.NET
runs within a process known as the ASP.NET worker process. All ASP.NET
functionality runs within the scope of this process.
A
regular Web server contains only a single ASP.NET worker process. This is
different from both Web farms and Web gardens:
·
A Web farm contains multiple ASP.NET worker
processes.
Each server in the group of servers handles a separate ASP.NET worker process.
Each server in the group of servers handles a separate ASP.NET worker process.
·
A Web garden contains multiple ASP.NET worker
processes.
Each CPU in the SMP server handles a separate ASP.NET worker process.
Each CPU in the SMP server handles a separate ASP.NET worker process.
Good
article to read ( Synchronization is the topic which need to consider for web
Garden and web Farm)
No comments:
Post a Comment