Http Handlers

This is a continuation of our series on HTTP. This Articles discusses the motivations and design concerns related to creation of Handler. The articles covers the technical details of what we discussed in the preceding article  Http Hacked.

Before we attempt to understand the concept of handlers we need to understand the working of HTTP. I would recommend going through the previous articles for this purpose:

1. story of www – between http and html – This is the main article that discusses the evolution of www, http protocol. Its motivation and the road map.
2. Http Hacked – The most important article to understand the current discussion. This is the second instalment on the running story on http. The episode mainly discusses how http was hacked for web programming.
3. Http Through Ages – This article is a technical overview of the changes between various versions of http and you may like to go through it for the completion of discussion.

Now lets quickly recap how an Http Server works.

 

Scenario 1. Http Server is requested to Serve a static resource

By static resource we mean a html document or an image or a downloadable content that always exists (or can exist) on the server, and all a server does is to pick it and pass it to the client. The following diagrams represents the scenario:

Any and every Http Server is designed to serve this kind of request. As such the request is handled in strict accordance with http protocol.

 

Scenario 2. Http Server is requested a Dynamic Resource

The situation get trickier when you need to serve a resource that doesn’t exist; rather it is created. More accurately – that is computed. An example could be – requesting a list of customers. The information exists in the database. It needs to be extracted and presented in a tabulated format. So we need a program that –

• Accepts users request and relevant parameters
  • Parameter may tell to get a list of priority customer
  • Filter customers based on geographical location and so on
• Executes relevant queries on to the database and extracts the necessary records
• Creates an HTML page with the extracted records in a presentable format.
• Sends the newly created html page to the user.

So we need a program. But how does this program relate to the web server. Web server need to delegate its work to this special program which is designed to handle the request. The overall interaction process is represented in following diagram:

 

 

The diagrams brings out following points clearly:

1. Web server really doesn’t know how exactly to use the dynamic resource (in our case customer.aspx)
2. It relies on an external application or extension to get the computation done. These extension are typically termed as http handlers.
3. A web server typically can delegate the computation to one of the many handlers.
4. Each Handler is supposed to process a particular kind of request which can be identified by url format.
5. A url format may mean
   1. In most of the cases a particular extension  – *.asp, *.aspx, *.php, *.jsp and so on
   2. It may also mean request associated with a particular folder. Eg. /cgi-bin/*
   3. It may be a particular absolute path – Eg /log/log.app
6. The web server checks the Url and then decides whom to delegate the request.

 

Developing The Handlers

 

As we already discussed in our previous article Http Hacked, that the need of such an extension was felt clearly. We needed a mechanism to extend the server in different and unpredictable ways. For this reason different vendors proposed their solution. The solutions had implementation differences, however, philosophically they had same working principle:

Define a set of guidelines and  API that will be used for creating a handler. The Handler will expose a certain well defined set of functionality that will be called by the web server to get the request processed.

Microsoft proposed an API layer and termed it as ISAPI – Internet Server API

Netscape, for example, proposed NSAPI – Netscape Server API.

 

Servers and handlers are supposed to be compliant with one of the available standards. For example IIS is an ISAPI compliant server and can work with any ISAPI  compliant handler. All ISAPI compliant handlers are supposed to work with every ISAPI compliant servers.

 

An ISAPI handler is typically written as a win32 dll and is designed in C/C++ language. However, other language choices are also available.

 

Deploying the Handler

Once a Http Handler is created, it needs to be registered with the web server and mapped with an url pattern. Following screenshots shows different ISAPI handlers registration with IIS 7.0.

Step 1: Start Internet Service Manager from Control Panel –>Administrative Tools

 

Step 2: Navigate to Http Handler Mapping section

 

Step 3: We will have a list of existing mapping. We can modify them or add new entries

 

Step 4: This is a sample mapping of .aspx files to aspnet_isapi.dll

 

 

 

Summary

 

In this section we looked at the roles of Http handlers and their deployment. In the next episode we will be checking deployment of http handler using asp.net.