Asp. NET's underlying system 2

Article guide

1.ASP. NET's underlying system 1

2.ASP. NET's underlying system 2

Introduction

Then the last ASP. 1 We're going to go down.

I. System.Web.HttpRuntime.ProcessRequestInternal

Let's see ProcessRequestInternal's ProcessRequest.

1. Create a new HttpContext instance for the request

2. Get a HttpApplication instance

3. Call HttpApplication.Init () to initialize the pipeline event

4.Init () trigger httpapplication.resumeprocessing () to start ASP.

A new HttpContext object is created, passing it a isapiworkerrequest that encapsulates the ISAPI ECB. The HttpContext object also contains a very useful collection of lists that you can use to store data about a particular request. The context object is created at the beginning of a request life cycle and is freed at the end of the request. So the data saved in the list collection is only valid for the current request.

Two. HttpApplication

Each request is routed to a HttpApplication object, The HttpApplication class creates a pool of HttpApplication objects for your ASP. It is responsible for loading the program and referring to each request distribution HttpApplication, the size of the HttpApplication object pool can be Configuration of the maxWorkerThreads option in the processmodel node of the. config.

The HttpApplication object pool, although started with fewer projects, also increases the number of objects in the pool when multiple requests need to be processed. For your Web program, HttpApplication is an external container that corresponds to the class defined by the Global.asax file. A standard-based Web program, which is the first login point you can actually see in the HTTP runtime.

HttpApplication is mainly used for the HTTP pipeline event controller, its interface is mainly composed of events.

BeginRequest

AuthenticateRequest

AuthorizeRequest

Resolverequestcache

AcquireRequestState

Prerequirestate

PostRequestHandlerExecute

ReleaseRequestState

Updaterequeststate

EndRequest

Each ASP. NET Web application runs in its own AppDomain, running multiple HttpApplication in the AppDomain, which are stored in an HttpApplication object pool managed by ASP.

Observing that the AppDomain ID remains the same, while the ID of the thread and the httpaapplication changes when the request is many, because HttpApplication is running in a collection, The next request may use the same HttpApplication instance again, so sometimes the ID of the HttpApplication is duplicated, and a HttpApplication instance object does not depend on a particular thread. They are simply assigned to the thread that handles the current request.

Thread by. NET ThreadPool provides services, by default, the threading model is a multithreaded apartment (MTA), and you can override the state of a thread cell by setting the property ascompat= "true" in the @page directive of the ASP. ASPCompat means that COM components will run in a secure environment. In fact, it is important that these HttpApplication objects run in the same AppDomain, which is how ASP. Web. config changes or separate ASP. NET pages can be verified across the AppDomain. Changing the value of Web. config causes the AppDomain to re-open. This ensures that all HttpApplication instances can see these changes, because when the AppDomain reloads, Those changes from ASP. NET will be re-read when the AppDomain is started, and any static references will reload when the AppDomain restarts.

These changes will cause the Web program to restart, for requests that already exist in the processing pipeline will continue to be processed through the original pipeline, and for those new requests, will be routed to the new AppDomain, in order to process these "pending requests", after these requests expire, the ASP. NET will force the AppDomain to shut down even if these requests are not processed. Therefore, it is possible to have the same HttpApplication instance in two AppDomain at a given time.

HttpApplication is responsible for the transfer of the request, notifying the application of what is happening by triggering the event. This is implemented as part of the HttpApplication.Init () method (System.Web.HttpApplication.InitInternal and Httpapplication.resumesteps ()). In this method, a series of events are created and started, including binding event handlers, and the event handlers in the Global.asax are automatically mapped to the corresponding events.

By registering in Web. config, httpmodules and httphandlers can be dynamically loaded and can be added to the event chain, httpmodules is actually the event handler, which can hook up the specified HttpApplication event, and Httphandle RS is an endpoint that can be invoked to handle "application-level request Processing".

HttpApplication itself does not know the data sent to the Web program, it is just an errand, it is a container of events, responsible for communication between events, passing HttpContext objects.

ASP. NET pipeline once successful, HttpApplication will trigger each event, each event will be triggered, and if the event is bound to the event handler, then these event handlers will be called to perform their task. The purpose of this process is to process the specified request by calling HttpHandler, and for ASP. HttpHandler is the core of the processing request mechanism. Asp. NET pages and Web service are HttpHandler implementations. HttpModule tends to process content before and after distributing it to the event handler

three. HttpModule

The essence of the module is the filter, Functionally similar to the ASP. NET request level ISAPI filtering, for each request that passes through the ASP. HttpApplication object, the module allows the requests to be intercepted in an event-handling method triggered by the HttpApplication object, which is stored in the external assembly as a class. Can be configured in Web. config. When the program starts to load, by implementing the specified interface and method, the module can be added to the HttpApplication event chain, multiple httpmodules can hook the same event, the order in which the events occur and the order in which they are configured in WEB.CONFG.

<configuration>

<sysytem. Web>

<HttpModules>

<add name= "Basicauthmodule" type= "Httphandlers.basicauth,webstore"/>

The module allows you to view each incoming Web request and perform actions based on the triggered event. The module is very useful, it can modify the request, output the content of the response, and provide custom authentication. You can also provide pre-response and post-response processing for each request from ASP in a specific program.

HttpModule like an ISAPI feeling, Because they look at every request that goes into the ASP, their limitations are only to view requests that map to an ASP or virtual directory, and to map to an ASP. NET, so you can view all the ASPX pages or any other custom extensions that have been mapped to the program.

Implement a HttpModule module that contains two methods: Init () and Dispose (), and the passed event arguments contain a reference to a HttpApplication object that gives you HttpContext access.

 Public classbasicauthcustommodule:ihttpmodule{ Public voidInit (HttpApplication application) {//* * Hook up any HttpApplication eventsApplication. AuthenticateRequest + =NewEventHandler ( This.   OnAuthenticateRequest); }    Public voidDispose () {} Public voidOnAuthenticateRequest (Objectsource, EventArgs EventArgs) {HttpApplication app=(HttpApplication) source; HttpContext Context=HttpContext.Current; ... .. DoWhat are you having to Do...} }

In the Init () method, you can hook up multiple events, so in one module, you can manage the operation of several different functions. When using HttpApplication events in HttpModules, Response.End () and Httpapplication.completerequest () The HttpApplication method causes ASP. NET to skip the event chain of the module.

Four. HttpHandler

HttpModule is triggered for each request to an incoming ASP. HttpHandler is heavier than processing a specified request mapping. HttpHandler inherits IHttpHandler, this excuse has a method processreuqest () and a property isreusable. ProcessRequest () can get a HttpContext.

The key operation of the HttpHandler is to write the output data to the response object, or rather to the outputstream of the response object, which is the output data that is actually returned to the client, at the bottom, The isapiworkerrequest is responsible for sending the OutputStream back to the ISAPI Ecb.writeclient method, because Ecb.writeclient is actually performing the output data that IIS produces.

Asp. NET's underlying system 2