January 22, 2021
Hot Topics:

Asynchronous Http Handlers

  • By Jason Clark
  • Send Email »
  • More Articles »
From CodeGuru.com's Programming Insights...

by Jason Clark of Wintellect

The new Web Forms model for the .NET Framework gets plenty of attention in magazine and Web articles, and rightly so. However, ASP.Net also allows developers to easily write server-side modules called Http Handlers in any .NET Language, such as C#. Http handlers are much more akin to a good old ISAPI DLL running in IIS.

Instead of being an object-oriented, event-driven model for creating Http responses, the Http handler simply allows the developer to output any text into the response stream, and what the handler outputs is what the browser gets. This is a fairly low-level approach to writing active server-side code, and has great potential for applications that require the utmost in scale-up scalability.

First, let's take a brief look at regular Http handlers.

Synchronous Http Handlers

The following is an example of a simple synchronous Http handler.

<%@ WebHandler Language="C#" Class="AsyncHttpHandler"%>

using System;
using System.Web;

public class AsyncHttpHandler : IHttpHandler {
  public void ProcessRequest(HttpContext context) {
    context.Response.Write("<H1>This is an Http handler.</H1>");

  public bool IsReusable {
    get { return true; }

Listing 1—Sync.ashx, a synchronous Http handler.

Copy the text in Listing 1 into a file with an .ashx extension and copy it into a virtual root directory for IIS (on a machine where the .NET Framework is installed). Now point a browser to the Web location and file name. ASP.Net will compile the code the first time the resource is requested. Each successive time the file is requested, the ProcessRequest() method is called to generate an Http response to send back to the client. The code in Listing 1 is a basic Http handler; a flexible ASP.Net feature indeed (and easier to write than an ISAPI DLL). But its main drawback is that it is not capable of being called asynchronously by ASP.Net.

Shortly I will explain how to create a more scalable asynchronous Http handler, but first let's look at the reasons why synchronous handlers can be less than perfect.

Most active server code is IO-bound rather than CPU-bound. What this means is that in general the bottleneck in producing a response is usually some second-tier network communication, database operation, or file-IO. The code in Listing 1, by the way, is CPU bound, and therefore works fine as a synchronous handler. IO-bound server code is common compared to CPU-bound server code, however.

Imagine an IO-bound scenario where a client request comes in to an Http handler. Let's say that the thread in ASP.Net's thread pool that is used to call the ProcessRequest() method is thread 1. When the Http handler code makes an IO request, latency is almost certain to occur, and the OS puts thread 1 into an efficient wait-state (to wait for the IO to complete). When a thread processing a request enters a wait state, ASP.Net awakens (or creates) another thread from its pool (thread 2) to serve another client request while thread 1 is blocked. This is the problem with synchronous handlers!

When an IO-bound Http handler is under a heavy load, the relationship described between thread 1 and thread 2 continues to occur between thread 2 and thread 3, thread 3 and thread 4, and so on. This is inefficient! Why should thread 2 be used to initiate work for the second client, when a perfectly good thread (thread 1) is sitting idle waiting on IO? The idle thread would be best utilized by doing more active work while IO is pending. This is how asynchronous Http handlers work.

Page 1 of 2

This article was originally published on July 10, 2002

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date