Asp. The httphandlers of net bottom architecture exploration

Modules are fairly low-level, and each request to the ASP.net application is triggered. The HTTP processor is more focused and processing requests that are mapped to this processor.

What the HTTP processor needs to implement is very simple, but it can become very powerful by accessing the HttpContext object. HTTP processor by implementing a very simple IHttpHandler interface (or its asynchronous version, IHttpAsyncHandler), This interface even contains only one method-processrequest ()-and a property isreusable. The key part is ProcessRequest (), This function takes an instance of a HttpContext object as an argument. This function is responsible for processing Web requests from beginning to end.

A separate, simple function? It's too easy, isn't it? Good, simple interface, but not weak! Remember that both WebForm and WebService are implemented as HTTP processors, so it's very powerful in this seemingly simple interface. The key is the fact that When a request arrives at the HTTP processor, all ASP.net internal objects are prepared and set up to handle the request. The main HttpContext object is to provide all the relevant request functions to receive input and output back to the Web server.

For an HTTP processing, all actions occur in the invocation of this single ProcessRequest () function. This is as simple as the following:

public void ProcessRequest(HttpContext context)
{
context.Response.Write("Hello World");
}

It can also be as complete and complex as a WebForm page engine that can render complex forms from an HTML template. What you need to do with this simple, but powerful interface depends entirely on your decision.

Because the context object is available to you, you can access request,response,session and cache objects, so you have the key features of all ASP.net requests, You can get the content submitted by the user and return the content you generated to the client. Remember the HttpContext object-it is your "friend" throughout the life cycle of the asp.net request.

The key operation of the processor should be to write the output to the response object or, more specifically, to the outputstream of the response object. This output is actually sent back to the client. Behind the scenes, Isapiworkerrequest manages the process of returning output streams to the ISAPI ECB. The WriteClient method is the method that actually produces the IIS output.

Figure 7-asp.net the request pipeline provides greater flexibility by forwarding the request through a series of event interfaces. Application a host container that loads Web applications and triggers events when a request arrives and passes through a pipeline. Each request goes along the path of the configured HTTP Filter and module (HTTP Filters and Modules, which should mean HTTP Module and HTTP Handler). Filters can check each request through a pipe, Handler allows application logic to be implemented or application-layer interfaces such as Web Form and webservice. To provide input and output to the application, The context object provides request-specific information during this process.

WebForm uses a series of very high-level interfaces in the framework to implement an HTTP processor, but actually webform render () The method is simple to use a HtmlTextWriter object to output its final result to context.Response.OutputStream end. So it's very dreamy, After all, even advanced tools such as WebForm are abstracted only on the request and response objects.

Here you may wonder what you really need to deal with in HTTP handler. Now that WebForm provides a simple, usable HTTP handler implementation, why do you need to consider something more low-level and give up this extensibility?

WebForm is very powerful for creating complex HTML pages, and business-level logic requires graphical layout tools and module-based pages. But the WebForm engine did a series of overhead Intensive task. If you want to read a file from the system and return it via code, it is more efficient not to return the file directly through the WebForm framework. If you want to do something like read a picture from a database, You don't need to use a page frame-you don't need a template and you're sure you don't need a Web page to capture user events from it.

There is no reason to create a Page object and session and capture page-level events-all of which need to perform additional code that does not help your task.

So the custom processor is more efficient. The processor can also be used to do things that WebForm can't do, for example, the ability to process requests without having physical files on the hard disk is also known as a virtual URL. To do this, verify that you have turned off the check file presence option in the Application Extensions dialog shown in Figure 1.

This is very common for content providers, like dynamic image processing, XML services, URL redirection services that provide vanity URLs, download management, and others that do not require a webform engine.

Asynchronous HTTP Handler

Most of the time in this article I'm talking about synchronization, but the ASP.net runtime can also support asynchronous operations with asynchronous HTTP handler. These processors automatically process "uninstall" into threads on separate thread pools and release the main asp.net thread. Enables the asp.net thread to handle other requests. Unfortunately in the 1.x version. NET, the "uninstall" process is still in the same thread pool, so this feature adds a little bit of performance. To create true asynchronous behavior, you have to create your own threads and manage them yourself in callback processing.

The current version of ASP.net 2.0 Beta 2 in Ihttphandlerasync (this should mean IHttpAsyncHandler, suspected author clerical error) interface and Page class have done some improvements to asynchronous processing, providing better performance, However, will these be retained in the final release version?