Http请求过程(asp.net frame work)

HTTP Pipelines

Securely Implement Request Processing, Filtering, and Content Redirection with HTTP Pipelines in ASP.NET

Tim Ewald and Keith Brown

This article assumes you're familiar with ASP.NET and C#

Level of Difficulty 1 2 3

SUMMARY

ASP.NET is a flexible and extensible framework for server-side HTTP programming. While most people think of ASP.NET in terms of pages served, there is a lower-level infrastructure sitting beneath this page model. The underlying plumbing is based on a pipeline of app, module, and handler objects. Understanding how this pipeline works is key if you want to get the most out of ASP.NET as an HTTP server platform, while making your process more efficient, and keeping your server secure. This article introduces the architecture of the pipeline and shows how you can use it to add sophisticated functionality to an ASP.NET-based app.

  Contents

The Pipeline Object Model 
The Pipeline Process Model 
HTTP Handlers 
Standard Handlers 
HTTP Modules 
The Pipeline Event Model 
HTTP Applications 
Security in the Pipeline 
Conclusion 

Most people think of ASP.NET in terms of pages—that is, executable templates for creating HTML to return to browsers. But that is just one of many possible ways to use the ASP.NET core infrastructure, the HTTP pipeline. The pipeline is the general-purpose framework for server-side HTTP programming that serves as the foundation for ASP.NET pages as well as Web Services. To qualify as a serious ASP.NET developer, you must understand how the pipeline works. This article explains how the HTTP pipeline processes requests.

The Pipeline Object Model

The types defined in the System.Web namespace process HTTP requests using a pipeline model. The general structure of the pipeline is shown in Figure 1. HTTP requests are passed to an instance of the HttpRuntime class, which represents the beginning of the pipe. The HttpRuntime object examines the request and figures out which application it was sent to (from the pipeline's perspective, a virtual directory is an application). Then it uses an HttpApplicationFactory to either find or create an HttpApplication object to process the request. An HttpApplication holds a collection of HTTP module objects, implementations of the IHttpModule interface. HTTP modules are filters that can examine and modify the contents of HTTP request and response messages as they pass through the pipeline. The HttpApplication object uses an HTTP handler factory to either find or create an HTTP handler object. HTTP handlers are endpoints for HTTP communication that process request messages and generate corresponding response messages. HTTP handlers and handler factories implement the IHttpHandler and IHttpHandlerFactory interfaces, respectively.

Figure 1 HTTP Pipeline Processing 

An HttpApplication, its modules, and its handler will only be used to process one request at a time. If multiple requests targeting the same application arrive simultaneously, multiple HttpApplication objects will be used. The HttpApplicationFactory and HttpHandlerFactory classes pool HttpApplication objects and HTTP handler objects, respectively, for efficiency's sake.

The pipeline uses an HttpContext object to represent each request/response pair. The object is passed to the HttpApplication, which in turn passes it to the handler. Each module can access the current HttpContext as well. The HttpContext object exposes properties representing the HTTP request and response messages, which are instances of the HttpRequest and HttpResponse classes, respectively. The HttpContext object also exposes properties representing security information and per-call, per-session, and per-application state. Figure 2 shows most of the interesting properties of the HttpContext class.

  Figure 2 Interesting HttpContext Properties

Property	Description
Application	Per-application cross-request state
Application Instance	Application object processing request
Cache	Per-application cached state
Handler	Handler object processing request
Items	Per-request state
Request	HTTP request message
Response	HTTP response message
Server	Utility functions
Session	Per-user cross-request state
User	User information

The ASP.NET HTTP pipeline is fully extensible. You can implement your own HTTP modules, handlers, and handler factories. You can also extend the behavior of the HttpApplication class.

The Pipeline Process Model

The ASP.NET HTTP pipeline relies on Microsoft® Internet Information Services (IIS) to receive the requests it is going to process (it can also be integrated with other Web servers). When IIS receives an HTTP request, it examines the extension of the file identified by the target URL. If the file extension is associated with executable code, IIS invokes that code in order to process the request. Mappings from file extensions to pieces of executable code are recorded in the IIS metabase. When ASP.NET is installed, it adds entries to the metabase associating various standard file extensions, including .aspx and .asmx, with a library called aspnet_isapi.dll.

When IIS receives an HTTP request for one of these files, it invokes the code in aspnet_isapi.dll, which in turn funnels the request into the HTTP pipeline. Aspnet_isapi.dll uses a named pipe to forward the request from the IIS service where it runs, inetinfo.exe, to an instance of the ASP.NET worker process, aspnet_wp.exe. (In Windows® .NET Server, ASP.NET integrates with the IIS 6.0 kernel-mode HTTP listener, allowing requests to pass from the operating system directly to the worker process without passing through inetinfo.exe.) The worker process uses an instance of the HttpRuntime class to process the request. Figure 3 illustrates the entire architecture.

Figure 3 ASP.NET Pipeline Architecture 

The HTTP pipeline always processes requests in an instance of the worker processes. By default, there will only be one worker process in use at a time. (If your Web server has multiple CPUs, you can configure the pipeline to use multiple worker processes, one per CPU.) This is a notable change from native IIS, which uses multiple worker processes in order to isolate applications from one another. The pipeline's worker process achieves isolation by using AppDomains. You can think of an AppDomain as a lightweight process within a process. The pipeline sends all HTTP requests targeting the same virtual directory to a single AppDomain. In other words, each virtual directory is treated as a separate application. This is another notable change from native IIS, which allowed multiple virtual directories to be part of the same application.

ASP.NET supports recycling worker processes based on a number of criteria, including age, time spent idle, number of requests serviced, number of requests queued, and amount of physical memory consumed. The global .NET configuration file, machine.config, sets thresholds for these values (see the processModel element). When an instance of aspnet_wp.exe crosses one of these thresholds, aspnet_isapi.dll launches a new instance of the worker process and starts sending it requests. The old instance terminates when it finishes processing pending requests. Recycling of worker processes promotes reliability by killing off processes before their performance begins to degrade from resource leaks or other runtime phenomena.

HTTP Handlers

HTTP handlers are simply classes that implement the IHttpHandler interface, as shown in the following lines of code:

Handlers can also implement the IHttpAsyncHandler interface if they want to support asynchronous invocation.