HttpHandler and HttpModule

Introduction

Whenever a request reaches an Microsoft Internet Information Services (IIS) Web server, IIS determines how to handle the file by examining the requested file's extension. Static files, like HTML pages, images, Cascading Style Sheet (CSS) files, and the like, are handled directly by IIS. Requests for Microsoft ASP.NET Web pages or Web services—files with extensions .aspx or .asmx—are handed off to the ASP.NET engine. Requests for files with the extension .asp are handed off to the classic ASP engine. The ASP.NET and ASP engine are responsible for generating the markup for the requested resource. For ASP.NET and classic ASP Web pages, this markup is HTML; for Web services, the markup is a SOAP response. Once the engine has successfully rendered the markup for the requested resource, this markup is returned to IIS, which then sends the markup back to the client that requested the resource.

This model of serving content—having IIS directly serve only static content, while delegating the rendering of dynamic content to separate engines—has two distinct advantages:

1. It provides a nice division of labor. IIS can focus on excelling at serving static content, and can leave the details for serving dynamic content to an external program. That is, IIS can focus on efficiently serving HTML pages and images while the ASP.NET engine can focus on efficiently rendering ASP.NET Web pages and Web services.
2. It allows for new dynamic server-side technologies to be added to IIS in a pluggable manner. Imagine if IIS was responsible for rendering ASP.NET Web pages itself, rather than relying on an external engine. In that case, each time a new version of ASP.NET came out—or any dynamic server-side technology, for that matter—a new version of IIS would need to be created that supported this new version. Those who wanted to use the latest version would have to update the version of IIS.

To have this model of serving content work, IIS needs a mapping of file extensions to programs. This information exists in the IIS metabase and can be configured via the Internet Services Manager, as we'll see in the next section. When a request comes into IIS, then, this mapping is consulted to determine where the request should be routed. Extensions like .aspx, .asmx, .ashx, .cs, .vb, .config, and others are all configured, by default, to be routed to the ASP.NET engine.

Whenever a request is routed from IIS to the ASP.NET engine, the ASP.NET engine performs a similar series of steps to determine how to properly render the requested file. Specifically, the ASP.NET engine examines the requested file's extension and then invokes the HTTP handler associated with that extension, whose job it is to render the requested file's markup.

Note   Technically, the ASP.NET engine will invoke either an HTTP handler or an HTTP handler factory. An HTTP handler factory is a class that returns an instance of an HTTP handler.

An HTTP handler is a class that knows how to render content for a particular type of Web content. For example, there is a different HTTP handler class in the .NET Framework for rendering ASP.NET Web pages than there is for rendering Web services. Just as IIS relies on external programs to serve dynamic content, the ASP.NET engine relies on different classes to render the content for a certain type of content.

By having the ASP.NET engine pluggable like IIS, the same advantages discussed earlier are realized by ASP.NET. Of particular interest is the fact that this model allows for developers to create new HTTP handler classes, and plug them into the ASP.NET engine. In this article, we'll examine precisely how to create custom HTTP handlers and use them in an ASP.NET Web application. We'll start with an in-depth look at how the ASP.NET engine determines what HTTP handler should service the request. We'll then see how to easily create our own HTTP handler classes with just a few lines of code. Finally, we'll look at a number of real-world HTTP handler examples that you can start using in your Web applications today.

Http Handlers

HTTP handlers are the .NET components that implement the System.Web.IHttpHandler interface. Any class that implements the IHttpHandler interface can act as a target for the incoming HTTP requests. HTTP handlers are somewhat similar to ISAPI extensions. One difference between HTTP handlers and ISAPI extensions is that HTTP handlers can be called directly by using their file name in the URL, similar to ISAPI extensions.

HTTP handlers implement the following methods.

Method Name	Description
ProcessRequest	This method is actually the heart of all http handlers. This method is called to process http requests.
IsReusable	This property is called to determine whether this instance of http handler can be reused for fulfilling another requests of the same type. HTTP handlers can return either true or false in order to specify whether they can be reused.

HTTP Modules

HTTP modules are .NET components that implement the System.Web.IHttpModule interface. These components plug themselves into the ASP.NET request processing pipeline by registering themselves for certain events. Whenever those events occur, ASP.NET invokes the interested HTTP modules so that the modules can play with the request.

An HTTP module is supposed to implement the following methods of the IHttpModule interface:

Method Name	Description
Init	This method allows an HTTP module to register its event handlers to the events in the HttpApplication object.
Dispose	This method gives HTTP module an opportunity to perform any clean up before the object gets garbage collected.

Read following for more info...

http://www.codeguru.com/csharp/.net/net_asp/article.php/c19389     

http://msdn.microsoft.com/en-us/library/ms972953.aspx