ASP. NET page request processing process

Page Compilation

For a specific. aspx ResourceProgramThe collection is generated in two steps. FirstSource codeIt is parsed and derived from the page class (or the derived class of the page) based on the obtained information. Then, the dynamically generated class will be compiled into an assembly, which will be cached to a temporary directory dedicated to ASP. NET.

As long as the connected aspx source file is not changed and the entire application is not restarted, the compiled page will always exist. Any changes to the connected aspx file will invalidate the related Assembly and force the HTTP Runtime Library to create a new assembly when the next request is sent to the page.

Editing files such as Web. config and Global. asax will restart the entire application. In this case, when a page is requested, all pages will be re-compiled. If the assembly in the bin folder is modified (new or replaced), all pages will be re-compiled.

Operating Mechanism

All resources provided by the IIS web server are organized by the extension. Any access request will be allocated to a specific runtime Process Module for actual processing. The module that can process Web Resources in the IIS context is an extension of the Internet Server Application Programming Interface (ISAPI)-a traditional Win32 DLL. IIS and ISAPI extensions use these DLL entry methods for dedicated communication protocols. When IIS requires an ISAPI extension to complete a task, it loads the corresponding DLL and calls the appropriate function through valid parameters.

When a resource request arrives, IIS first determines the requested resource type. Static resources are directly processed by IIS without calling any external modules. IIS accesses the requested file on the Local Web server and writes its content to the output console and returns it to the browser. Resource ing information is stored in the IIS metabase. ASP. NET makes modifications to the IIS metadatabase during installation so that aspnet_isapi.dll can process some typical ASP. NET Resources. Some of them are listed:

Iis5 Process Model

If the ASP. NET application is deployed in the system before Windows Server 2003, you can only select the iis5.0 process model. In this model, aspnet_isapi.dll does not process the aspx file, but acts as a scheduler. Collect all information about the URL and underlying resources, and send it to another special process, aspnet_wp.exe. The communication between ISAPI extensions and working processes is completed through the named pipe (Named Pipe. Under a single CPU, a copy of the worker process is always running, and all active web applications are supported. Multiple worker processes are allowed to run under multiple CPUs, and each process corresponds to one available CPU.

Each web application is identified by its virtual directory from an independent application domain (appdomain ). When a virtual directory is requested by the client for the first time, the ASP. NET workflow creates a new appdomain. Then, the ASP. NET Runtime Library loads all the required assemblies and gives control to the managed HTTP pipeline, which actually processes the request.

If the client requests a running web application, the ASP. NET runtime only forwards the request to the existing appdomain associated with its virtual directory. If the Assembly for processing the current page is not loaded by the appdomain, it is created dynamically. If it has been created during the first call, it is directly used.

Iis6.0 Process Model

If the operating system of the Web server is Windows Server 2003 or later, the iis6.0 process model is the default choice of ASP. NET. The iis6.0pipeline is centered on a workflow named w3wp.exe. A copy of the executable program is shared by all web applications allocated to the same application pool. Iis6.0 enables customization of application pools to isolate various applications hosted on Web servers.

The w3wp.exe workflow loads aspnet_isapi.dll. Then, the ISAPI extension loads the Common Language Runtime (CLR), starts the pipeline during Asp.net runtime, and processes the request. With the iis6.0 process model, the built-in working processes of Asp.net will be disabled.

Iis6.0 implements the HTTP listener in the form of a kernel-level module. All input requests are first managed by a driver (HTTP. sys. The HTTP. SYS driver listens to requests and appends them to the corresponding application pool Request queue. A module called "Web Management Service" reads the IIS metadatabase and instructs the HTTP. SYS driver to create a request queue. The number of queues is the same as the number of application pools registered in the metadatabase.

In general, asp.netruns faster with the iis6.0input model, because inetinfo.exe (IIS Management Service) and the working process do not need to communicate with each other. HTTP requests are directly delivered to the CLR worker process. In addition, ASP. NET work processes are not special processes, but just copies of IIS work processes. In this way, the burden of recycling processes, caching pages, and monitoring running conditions will be borne by IIS.

Description of the requested page

Each input request that references the aspx resource is mapped to the derived class of the page. The class name for processing the request is first determined in the Asp.net HTTP runtime environment. The page url is associated with the class name through some naming conventions. For example, if the request page is default. aspx, You can infer that the associated class is ASP. default_aspx. If the current Assembly loaded to the appdomain does not contain the class name, the HTTP runtime will issue the creation and compilation commands for this class. Source of this aspx ResourceCodeWill be parsed to create the source code of the class, and the results will be saved in the temporary Asp.net folder temporarily. Next, the class is compiled and loaded into the memory to process the request. When a request on the same page arrives again, the compilation process will not be executed because the class already exists.

The ASP. default_aspx class inherits from the page class or the page derived class. More specifically, the base class ASP. default_aspx (created by vs) is merged with the hidden class code (dynamically organized by the ASP. net http Runtime Library.

Request Processing

After the requested aspx class is created, the HTTP runtime environment calls this class through the public interface ihttphandler. The root page class implements this interface, which contains two member processrequest methods and Boolean isreusable attributes. Once the HTTP Runtime library obtains an instance that represents the requested resource class, it calls the processrequest method to start processing, so that it can end after responding to the browser. The whole process of calling and executing processrequest and the event triggered is called "the lifecycle of the page ".

ASP. NET worker threads send any input requests to the HTTP pipeline. The HTTP pipeline is a fully scalable managed object chain, working in a similar way as the "Pipeline" in the general sense. All these objects constitute the so-called ASP. net http runtime environment.

Httpruntime object

The page request is passed to every object in the MPs queue that processes the original HTTP payload. The tag code to be sent to the browser is generated on the terminal of the link. The httpruntime class is the entrance point of the pipeline. For each input request, the ASP. Net working thread creates an instance of the httpruntime class and calls its processrequest to activate the HTTP pipeline. Note: although the names of httpruntime. processrequest and ihttphandler are similar, there is no relationship between them.

The httpruntime class contains many private and internal methods, but only three static methods are exposed: Close, processrequest, and unloadappdomain.

The httpruntime object initializes the internal objects that are used to process page requests. These secondary objects include the cache manager and the file system monitor (used to detect changes to files that comprise the application ). After the processrequest method is called, The httpruntime object starts to process the page to be sent to the browser. It creates a new context for the request and initializes a special text writer object, which is used to cache the markup code. The context object is an instance of the httpcontext class, which encapsulates all http-specific information related to the request.

Then, the httpruntime object uses the context information to find or create a web application object that can process the request. You can locate a web application by adding the virtual directory information in the URL. The object used to search for or create an application is httpapplicationfactory, which is an internal object used to return valid objects that can process the request.

Application Factory

During the lifetime of the application, the httpapplicationfactory object maintains many httpapplication objects, which are used to process input HTTP requests. When the program factory object is called, it verifies whether the requested target virtual folder exists. If the application is running, the factory obtains an httpapplication object from the available Object pool and sends it to the request. If no application is available, a new httpapplication instance is created.

If the virtual directory has not been called, an httpapplication object is created for the virtual directory in the new appdomain. In this way, if the application file global. asax exists, the httpapplication object needs to compile it and create an assembly that represents the actually requested page. This process is equivalent to starting an application. The httpapplication object is used to process page requests. Each time a page request is processed, multiple objects are used to process concurrent requests ).

Httpapplication object

Httpapplication is a base class that represents a running ASP. NET application. A running ASP. NET application is represented by a dynamically created class inherited from httpapplication. If global. asax exists, the source code of the dynamically generated application class can be created by parsing its content. If global. asax is available, the application class is created and named ASP. global_asax. Otherwise, the base class httpapplication is used.

The instance of the httpapplication derived class is responsible for managing the entire lifecycle of the requests allocated to it. The instance will be reused only after the request is processed. Httpapplication maintains a series of HTTP module objects that can filter or even modify the requested content. A registered module may be called at any time during request traversal.

The httpapplication object can determine the type of the object representing the requested resource. Then, httpapplication uses the corresponding handler factory to obtain the object representing the requested resource. The factory may use an existing assembly to instantiate the class instance of the requested resource, or dynamically create the required assembly and then instantiate the object. The handler factory object implements the ihttphandlerfactory interface and is responsible for returning the HTTP processing program, the managed object that processes HTTP requests. An ASP. NET page is just a processing program object (that is, a class instance that implements the ihttphandler interface ).

Page Factory

Once the httpapplication object is in charge of the request, you must select an appropriate processing program and create an instance of the processing program. For page-oriented requests, the corresponding factory name is pagehandlerfactory. Httpapplication reads the information in the

The handler factory does not compile each time the requested resource is called. The compiled code is stored in the ASP. NET temporary directory of the Web server.

When a request is received, the page processing factory will create an object instance representing the requested page. The page object inherits from the system. Web. UI. Page class, which implements the ihttphandler interface. The page object is returned to the application factory and then passed to the httpruntime object. The final step is completed by the ASP. NET Runtime Library. The ASP. NET Runtime Library calls the processrequest method of the ihttphandler Page Object. This enables the page to execute user-defined code and generate a tag for the browser.

Summary

The HTTP page request processing process is as follows:

Page Compilation

The assemblies of specific. aspx resources are generated in two steps. First, the source code of the resource file is parsed. Based on the obtained information, the corresponding class is derived from the page class (or the derived class of the page. Then, the dynamically generated class will be compiled into an assembly, which will be cached to a temporary directory dedicated to ASP. NET.

As long as the connected aspx source file is not changed and the entire application is not restarted, the compiled page will always exist. Any changes to the connected aspx file will invalidate the related Assembly and force the HTTP Runtime Library to create a new assembly when the next request is sent to the page.

Editing files such as Web. config and Global. asax will restart the entire application. In this case, when a page is requested, all pages will be re-compiled. If the assembly in the bin folder is modified (new or replaced), all pages will be re-compiled.

Operating Mechanism

All resources provided by the IIS web server are organized by the extension. Any access request will be allocated to a specific runtime Process Module for actual processing. The module that can process Web Resources in the IIS context is an extension of the Internet Server Application Programming Interface (ISAPI)-a traditional Win32 DLL. IIS and ISAPI extensions use these DLL entry methods for dedicated communication protocols. When IIS requires an ISAPI extension to complete a task, it loads the corresponding DLL and calls the appropriate function through valid parameters.

When a resource request arrives, IIS first determines the requested resource type. Static resources are directly processed by IIS without calling any external modules. IIS accesses the requested file on the Local Web server and writes its content to the output console and returns it to the browser. Resource ing information is stored in the IIS metabase. ASP. NET makes modifications to the IIS metadatabase during installation so that aspnet_isapi.dll can process some typical ASP. NET Resources. Some of them are listed:

Iis5 Process Model

If the ASP. NET application is deployed in the system before Windows Server 2003, you can only select the iis5.0 process model. In this model, aspnet_isapi.dll does not process the aspx file, but acts as a scheduler. Collect all information about the URL and underlying resources, and send it to another special process, aspnet_wp.exe. The communication between ISAPI extensions and working processes is completed through the named pipe (Named Pipe. Under a single CPU, a copy of the worker process is always running, and all active web applications are supported. Multiple worker processes are allowed to run under multiple CPUs, and each process corresponds to one available CPU.

Each web application is identified by its virtual directory from an independent application domain (appdomain ). When a virtual directory is requested by the client for the first time, the ASP. NET workflow creates a new appdomain. Then, the ASP. NET Runtime Library loads all the required assemblies and gives control to the managed HTTP pipeline, which actually processes the request.

If the client requests a running web application, the ASP. NET runtime only forwards the request to the existing appdomain associated with its virtual directory. If the Assembly for processing the current page is not loaded by the appdomain, it is created dynamically. If it has been created during the first call, it is directly used.

Iis6.0 Process Model

If the operating system of the Web server is Windows Server 2003 or later, the iis6.0 process model is the default choice of ASP. NET. The iis6.0pipeline is centered on a workflow named w3wp.exe. A copy of the executable program is shared by all web applications allocated to the same application pool. Iis6.0 enables customization of application pools to isolate various applications hosted on Web servers.

The w3wp.exe workflow loads aspnet_isapi.dll. Then, the ISAPI extension loads the Common Language Runtime (CLR), starts the pipeline during Asp.net runtime, and processes the request. With the iis6.0 process model, the built-in working processes of Asp.net will be disabled.

Iis6.0 implements the HTTP listener in the form of a kernel-level module. All input requests are first managed by a driver (HTTP. sys. The HTTP. SYS driver listens to requests and appends them to the corresponding application pool Request queue. A module called "Web Management Service" reads the IIS metadatabase and instructs the HTTP. SYS driver to create a request queue. The number of queues is the same as the number of application pools registered in the metadatabase.

In general, asp.netruns faster with the iis6.0input model, because inetinfo.exe (IIS Management Service) and the working process do not need to communicate with each other. HTTP requests are directly delivered to the CLR worker process. In addition, ASP. NET work processes are not special processes, but just copies of IIS work processes. In this way, the burden of recycling processes, caching pages, and monitoring running conditions will be borne by IIS.

Description of the requested page

Each input request that references the aspx resource is mapped to the derived class of the page. The class name for processing the request is first determined in the Asp.net HTTP runtime environment. The page url is associated with the class name through some naming conventions. For example, if the request page is default. aspx, You can infer that the associated class is ASP. default_aspx. If the current Assembly loaded to the appdomain does not contain the class name, the HTTP runtime will issue the creation and compilation commands for this class. The source code of the aspx resource will be parsed to create the source code of the class, and the result will be saved in the temporary Asp.net folder temporarily. Next, the class is compiled and loaded into the memory to process the request. When a request on the same page arrives again, the compilation process will not be executed because the class already exists.

The ASP. default_aspx class inherits from the page class or the page derived class. More specifically, the base class ASP. default_aspx (created by vs) is merged with the hidden class code (dynamically organized by the ASP. net http Runtime Library.

Request Processing

After the requested aspx class is created, the HTTP runtime environment calls this class through the public interface ihttphandler. The root page class implements this interface, which contains two member processrequest methods and Boolean isreusable attributes. Once the HTTP Runtime library obtains an instance that represents the requested resource class, it calls the processrequest method to start processing, so that it can end after responding to the browser. The whole process of calling and executing processrequest and the event triggered is called "the lifecycle of the page ".

ASP. NET worker threads send any input requests to the HTTP pipeline. The HTTP pipeline is a fully scalable managed object chain, working in a similar way as the "Pipeline" in the general sense. All these objects constitute the so-called ASP. net http runtime environment.

Httpruntime object

The page request is passed to every object in the MPs queue that processes the original HTTP payload. The tag code to be sent to the browser is generated on the terminal of the link. The httpruntime class is the entrance point of the pipeline. For each input request, the ASP. Net working thread creates an instance of the httpruntime class and calls its processrequest to activate the HTTP pipeline. Note: although the names of httpruntime. processrequest and ihttphandler are similar, there is no relationship between them.

The httpruntime class contains many private and internal methods, but only three static methods are exposed: Close, processrequest, and unloadappdomain.

The httpruntime object initializes the internal objects that are used to process page requests. These secondary objects include the cache manager and the file system monitor (used to detect changes to files that comprise the application ). After the processrequest method is called, The httpruntime object starts to process the page to be sent to the browser. It creates a new context for the request and initializes a special text writer object, which is used to cache the markup code. The context object is an instance of the httpcontext class, which encapsulates all http-specific information related to the request.

Then, the httpruntime object uses the context information to find or create a web application object that can process the request. You can locate a web application by adding the virtual directory information in the URL. The object used to search for or create an application is httpapplicationfactory, which is an internal object used to return valid objects that can process the request.

Application Factory

During the lifetime of the application, the httpapplicationfactory object maintains many httpapplication objects, which are used to process input HTTP requests. When the program factory object is called, it verifies whether the requested target virtual folder exists. If the application is running, the factory obtains an httpapplication object from the available Object pool and sends it to the request. If no application is available, a new httpapplication instance is created.

If the virtual directory has not been called, an httpapplication object is created for the virtual directory in the new appdomain. In this way, if the application file global. asax exists, the httpapplication object needs to compile it and create an assembly that represents the actually requested page. This process is equivalent to starting an application. The httpapplication object is used to process page requests. Each time a page request is processed, multiple objects are used to process concurrent requests ).

Httpapplication object

Httpapplication is a base class that represents a running ASP. NET application. A running ASP. NET application is represented by a dynamically created class inherited from httpapplication. If global. asax exists, the source code of the dynamically generated application class can be created by parsing its content. If global. asax is available, the application class is created and named ASP. global_asax. Otherwise, the base class httpapplication is used.

The instance of the httpapplication derived class is responsible for managing the entire lifecycle of the requests allocated to it. The instance will be reused only after the request is processed. Httpapplication maintains a series of HTTP module objects that can filter or even modify the requested content. A registered module may be called at any time during request traversal.

The httpapplication object can determine the type of the object representing the requested resource. Then, httpapplication uses the corresponding handler factory to obtain the object representing the requested resource. The factory may use an existing assembly to instantiate the class instance of the requested resource, or dynamically create the required assembly and then instantiate the object. The handler factory object implements the ihttphandlerfactory interface and is responsible for returning the HTTP processing program, the managed object that processes HTTP requests. An ASP. NET page is just a processing program object (that is, a class instance that implements the ihttphandler interface ).

Page Factory

Once the httpapplication object is in charge of the request, you must select an appropriate processing program and create an instance of the processing program. For page-oriented requests, the corresponding factory name is pagehandlerfactory. Httpapplication reads the information in the

The handler factory does not compile each time the requested resource is called. The compiled code is stored in the ASP. NET temporary directory of the Web server.

When a request is received, the page processing factory will create an object instance representing the requested page. The page object inherits from the system. Web. UI. Page class, which implements the ihttphandler interface. The page object is returned to the application factory and then passed to the httpruntime object. The final step is completed by the ASP. NET Runtime Library. The ASP. NET Runtime Library calls the processrequest method of the ihttphandler Page Object. This enables the page to execute user-defined code and generate a tag for the browser.

Summary

The HTTP page request processing process is as follows: