• Choose a category
• All
• Classic-Fiction

HTTP handlers need be registered with the application. You do that in the application’s web.config file in the section of , in the section of as explained in Chapter 3, or in both places. If your application runs under IIS 7.x in integrated mode, you can also configure HTTP handlers via the Handler Mappings panel of the IIS Manager.

The IHttpHandler Interface

Want to take the splash and dive into HTTP handler programming? Well, your first step is getting the hang of the IHttpHandler interface. An HTTP handler is just a managed class that implements that interface. As mentioned, a synchronous HTTP handler implements the IHttpHandler interface; an asynchronous HTTP handler, on the other hand, implements the IHttpAsyncHandler interface. Let’s tackle synchronous handlers first.

The contract of the IHttpHandler interface defines the actions that a handler needs to take to process an HTTP request synchronously.

Members of the IHttpHandler Interface

The IHttpHandler interface defines only two members: ProcessRequest and IsReusable, as shown in Table 4-1. ProcessRequest is a method, whereas IsReusable is a Boolean property.

Table 4-1. Members of the IHttpHandler Interface

Member

Description

IsReusable

This property provides a Boolean value indicating whether the HTTP runtime can reuse the current instance of the HTTP handler while serving another request.

ProcessRequest

This method processes the HTTP request from start to finish and is responsible for processing any input and producing any output.

The IsReusable property on the System.Web.UI.Page class—the most common HTTP handler in ASP.NET—returns false, meaning that a new instance of the HTTP request is needed to serve each new page request. You typically make IsReusable return false in all situations where some significant processing is required that depends on the request payload. Handlers used as simple barriers to filter special requests can set IsReusable to true to save some CPU cycles. I’ll return to this subject with a concrete example in a moment.

The ProcessRequest method has the following signature:

void ProcessRequest(HttpContext context);

It takes the context of the request as the input and ensures that the request is serviced. In the case of synchronous handlers, when ProcessRequest returns, the output is ready for forwarding to the client.

A Very Simple HTTP Handler

The output for the request is built within the ProcessRequest method, as shown in the following code:

using System.Web;

namespace AspNetGallery.Extensions.Handlers

{

public class SimpleHandler : IHttpHandler

{

public void ProcessRequest(HttpContext context)

{

const String htmlTemplate = "" +

"

Hello I'm: " +

"{1}

"";

var response = String.Format(htmlTemplate,

"HTTP Handlers", context.Request.Path);

context.Response.Write(response);

}

public Boolean IsReusable

{

get { return false; }

}

}

}

You need an entry point to be able to call the handler. In this context, an entry point into the handler’s code is nothing more than an HTTP endpoint—that is, a public URL. The URL must be a unique name that IIS and the ASP.NET runtime can map to this code. When registered, the mapping between an HTTP handler and a Web server resource is established through the web.config file:

path="hello.axd"

type="Samples.Components.SimpleHandler" />

preCondition="integratedMode"

verb="*"

path="hello.axd"

type="Samples.Components.SimpleHandler" />

The section lists the handlers available for the current application. These settings indicate that SimpleHandler is in charge of handling any