HTTP Handler Overview

In Chapter 1, we provided an overview of the entire request-processing cycle in an ASP.NET Web application and the components involved in that process. An HTTP handler performs the actual work associated with the request. At a high level, the HTTP handler consumes the incoming request data sent to it by the client application and generates an outgoing response containing the results of its request-processing logic.

The HTTP runtime identifies the appropriate HTTP handler to service an incoming request based on the URL of the incoming request. It is typical for the HTTP runtime to create an instance of the HTTP handler directly. However, ASP.NET also allows you to provide an associated HTTP handler factory that can customize the instantiation of your HTTP handler.

ASP.NET provides a number of built-in HTTP handlers and HTTP handler factories in the System.Web and System.Web.UI namespaces. Table 19-1 lists some of these.

Table 19-1. Common HTTP Handlers and HTTP Handler Factories

File Types	HTTP Handler or HTTP Handler Factory	Description
.aspx files	PageHandlerFactory	Creates an instance of a dynamically compiled, derived Page class that is used as the HTTP handler
.asmx files	WebServiceHandlerFactory	Creates an instance of a dynamically compiled Web service implemented within the file, which is used as the HTTP handler
.ashx files	SimpleHandlerFactory	Creates an instance of a dynamically compiled HTTP handler implemented within the file
.ascx, .asax, .config, .cs, and .vb files	HttpForbiddenHandler	Prevents access to these files because they are meant for server-side use only
Other extensions	StaticFileHandler	Simply outputs the content of the file as its response

You can register your own handler implementations with the HTTP run ­time by using configuration entries that map URLs to your handler class within the <httpHandlers> section of a Web application's web.config file. The built-in HTTP handlers are registered for all applications in the machine.config file. The following is a fragment from the machine.config file:

 <configuration> <system.web>  <httpHandlers> <addverb="*"path="*.aspx"type="System.Web.UI.PageHandlerFactory"/> <addverb="*"path="*.ashx"type="System.Web.UI.SimpleHandlerFactory"/> <addverb="*"path="*.ascx"type="System.Web.HttpForbiddenHandler"/> <addverb="*"path="*.config"type="System.Web.HttpForbiddenHandler"/> <addverb="GET,HEAD"path="*"type="System.Web.StaticFileHandler"/> <addverb="*"path="*"type="System.Web.HttpMethodNotAllowedHandler"/>  </httpHandlers>  </system.web> </configuration> 

An HTTP handler can process a request in a variety of ways. The page handler handles .aspx files and returns HTML markup text by rendering the page and the controls it contains. The XML Web service handler associated with an .asmx file returns a SOAP response by executing a Web method, or it might generate a Web Services Description Language (WSDL) specification of the service based on the query string of the request. The handler associated with .ascx and .config files simply generates an error page, thereby preventing access to these files because they aren't meant to be viewable. The XmlHandler that we will implement later in this chapter generates XML markup. The ImageLabelHandler example appearing later in this chapter generates binary JPEG content. In essence, the HTTP runtime does not place arbitrary limitations on the processing that a handler can perform and allows the handler implementation to generate any response supported by the HTTP protocol.

The HTTP handler extensibility feature of ASP.NET is equivalent to the ISAPI filter feature provided by the Microsoft Internet Information Services (IIS) Web server. An ISAPI filter is an extensibility mechanism that allows you to implement request-handling logic for specific URLs or file extensions in C or C++. ASP.NET provides a vastly simpler model. In the ASP.NET model, you develop your custom-handling logic by implementing a simple managed class in any .NET programming language, and ASP.NET handles all the plumbing required to interact with IIS.

The IHttpHandler Interface

You can create an HTTP handler by implementing the System.Web.IHttpHandler interface, which is defined as follows :

 publicinterfaceIHttpHandler{ publicboolIsReusable{get;} publicvoidProcessRequest(HttpContextcontext); } 

This interface contains two members that you must implement:

• The IsReusable property determines whether the HTTP runtime can reuse an HTTP handler instance to handle multiple requests .

• The ProcessRequest method receives an instance of the HttpContext class and implements the logic of the handler. The context object contains information specific to the current request. In particular, this object provides access to the Request ( System.Web.HttpRequest ) object, which includes the request URL and data passed into the handler, and the Response ( System.Web.HttpResponse ) object, which is used by the handler to write out the result it generates.

The IHttpHandlerFactory Interface

The HTTP runtime allows you to customize the creation of your HTTP handler implementation by providing an associated IHttpHandlerFactory implementation. For example, in ASP.NET, .aspx files are associated with the PageHandlerFactory . The PageHandlerFactory parses an .aspx file and dynamically creates a class that derives from the Page class to represent the contents of the file as described in Chapter 2, "Page Programming Model." This derived page class then serves as the HTTP handler. The IHttpHandlerFactory interface is defined as follows:

 publicinterfaceIHttpHandlerFactory{ publicIHttpHandlerGetHandler(HttpContextcontext, stringrequestType,stringurl,stringpathTranslated); publicvoidReleaseHandler(IHttpHandlerhandler); } 

The GetHandler method allows you to create your HTTP handler based on the request data. The ReleaseHandler method allows you to clean up any resources if applicable , once your handler has been used to process a request. If you do not need to execute any custom logic to create your HTTP handler (that is, your implementation of GetHandler simply instantiates an instance of your handler), then you do not need to implement a handler factory.