Dr. Dobb's | Built-in HTTP Handlers: ASHX resources

Built-in HTTP Handlers: ASHX resources

ASP.NET automatically registers itself as the handler of ASHX resources. You can save yourself the editing of the metabase if you choose this extension for your custom handlers.

October 24, 2007
URL:http://www.drdobbs.com/global-developer/built-in-http-handlers-ashx-resources/202601357

In ASP.NET, an HTTP handler is the component that takes care of serving any requests. It is an instance of a class that implements the IHttpHandler interface. The interface counts on two methods. The ProcessRequest method is the central console that governs the processing of the request. For example, the System.Web.UI.Page class-the base class for all ASP.NET run-time pages-implements the IHttpHandler interface, and its ProcessRequest method is responsible for loading and saving the view state and for firing events such as Init, Load , PreRender , and the like. The second method is IsReusable and returns a Boolean value. You use it to indicate whether or not the handler can be reused or a new one is required for each request.

An HTTP handler is designed to process one or more URL extensions. Handlers can be given an application or machine scope, which means they can process the assigned extensions within the context of the current application or all applications installed on the machine. Of course, this is accomplished by making changes to either machine.config or a local Web.config file, depending upon the scope you desire. Here's how you register a HTTP handler to serve a particular request:


<system.web>
  <httpHandlers>
    <add verb="*" path="demo.aspx" type= "Samples.Demo, MyLib" />
  </httpHandlers>
</system.web>

It reads like this: "Whenever the demo.aspx URL is requested, regardless of the verb used, please use the ProcessRequest method in the Samples.Demo class in the MyLib assembly to serve the request." In this case, you are simply "logically" redirecting a request for demo.aspx to a different markup dynamically generated by your class. The path attribute can contain wildcards such as *.xyz meaning that all requests with that extensions will be mapped to your handler.

ASP.NET requests, though, always pass through IIS and must be recognized by IIS as requests that ASP.NET knows how to handle. When you install ASP.NET on a server machine it automatically registers itself as the handler of a number of extensions, including AXD and ASHX, but not, say, XYZ. This means that in order to handle XYZ requests through your handler you must modify the IIS metabase to map XYZ extensions to ASP.NET. Second, you must configure the web.config file of your application to redirect to a particular handler.

You can save yourself the editing of the metabase if you choose an AXD or ASHX extension for your custom handlers. However, for an AXD extension you still need to write in the web.config the name of the HTTP handler class for the request.

ASHX handlers, instead, are self-configured. If you write a handler with this extension you neither need to edit the IIS metabase nor the ASP.NET web.config. In ASP.NET, an ASHX resource is automatically recognized as a HTTP handler and the name of the class to use is read from a directive you have to place in the file. Here's an example:


<%@ WebHandler Language="C#" Class="Samples.DynImage" %>

Save this line to a file with an ASHX extension and then write a class named Samples.DynImage that implements IHttpHandler. After this, all that remains to do is using the URL that ends with the ASHX extensions from within the pages of the site. Without further effort.

The @WebHandler directive replaces the registration of the URL in the httpHandlers section of the web.config file. When an ASHX resource is requested, ASP.NET reads the contents of the @WebHandler directive, figures out the class to use and proceeds.

In terms of performance, there's virtually no difference between AXD and ASHX resources. In terms of ease of deployment, instead, ASHX are the preferred choice.