……………………………………………….Expertise in .NET Technologies

  • Categories

  • Advertisements

The HttpApplication

Posted by Ravi Varma Thumati on July 16, 2009

As soon as ASP.NET 1.0 was released, it offered a huge improvement over classic ASP by introducing well-defined code processing modules that together form the ASP.NET HTTP pipeline. Classic ASP was patched together from several disparate components (IIS, the Web Application Manager, and the ASP ISAPI DLL). The Request and Response objects were COM objects hanging off the threads owned by IIS. If you wanted to do any processing outside the context of ASP, you needed to write an ISAPI filter. If you wanted to write code to execute during processing, it had to occur within a COM object implementing IDispatch (severely limiting the available types of data you could use and negatively affecting performance). If you wanted to write any request-handling code (outside the context of ASP), you had to write a separate ISAPI DLL. The ASP.NET HTTP pipeline includes the facilities to do these things, but in a much more manageable way.

In ASP.NET, your application has the opportunity to perform preprocessing and post processing within HttpModules. If you use IIS 5.x or 6.x as your Web server, the ASP.NET pipeline stands by itself, and requests are processed completely by ASP.NET as soon as aspnet_isapi.dll hands control off to the ASP.NET worker process. If you’re using IIS 7.0 as your Web server, the ASP.NET pipeline is integrated into the server, allowing you to apply most ASP.NET services to non-ASP.NET content. In any case, your application also has the opportunity to process application-wide events using the HttpApplication object. Because of ASP.Net object model, the need for separate COM-based scripting objects on the server disappears. The endpoint of all requests is an implementation of IHttpHandler. ASP.NET already includes some useful implementations of IHttpHandler (that is, System.Web.UI.Page and System.Web.Services .WebService). However, you may easily write your own (as we’ll see later).

The IIS 5.x and IIS 6.x Pipeline

Once a request comes into the AppDomain managed by the ASP.NET runtime, ASP.NET uses the HttpWorkerRequest class to store the request information. Following that, the runtime wraps the request’s information in a class named HttpContext. The HttpContext class includes all the information you’d ever want to know about a request, including references to the current request’s HttpRequest and HttpResponse objects. The runtime produces an instance of HttpApplication (if one is not already available) and then fires a number of applicationwide events (such as BeginRequest and AuthenticateRequest). These events are also pumped through any HttpModules attached to the pipeline. Finally, ASP.NET figures out what kind of handler is required to handle the request, creates one, and asks the handler to process the request. After the handler deals with the request, ASP.NET fires a number of post-processing events (like EndRequest) through the HttpApplication object and the HttpModules.

The IIS 7.0 Integrated Pipeline

The Integrated IIS 7.0 pipeline is very similar to the ASP.NET HTTP pipeline that’s been around since ASP.NET was first released (which you see in Figure 2-5). As you can see from earlier investigations using the IIS 7.0 management console, the IIS 7.0 Integrated pipeline employs modules and handlers just like earlier versions of the ASP.NET HTTP pipeline. However, whereas ASP.NET HTTP pipeline runs entirely within the ASP.NET worker process, IIS 7.0 runs the pipeline as directed by IIS. The Integrated pipeline in IIS 7.0 works in very much the same way as the ASP.NET pipeline, so the application-wide events exposed through the HttpApplication events work just as before (we’ll discuss application-wide events in detail later). When running your application through IIS 7.0 in integrated mode, your request no longer passes through aspnet_isapi.dll. IIS 7.0 pushes the request through the modules and handlers directly.

Tapping the Pipeline

While some of the parts within the pipeline are unavailable to you as a developer, several parts are available directly and provide a useful means of managing your request as it goes through the pipeline. The most important parts of the pipeline that you can touch include the HttpApplication, the HttpContext, the HttpModule, and the HttpHandler.

The following sections supply some details about these critical sections within the HTTP request path.

The HttpApplication

At this point, you understand the nature of a Web application as being very different from that of a normal desktop application. The code that you’re writing is responsible for spitting some HTML response back to a client. In many ways, the model hearkens back to the terminal mainframe model prevalent during the mid-1970s. In ASP.NET, the endpoint of a request is an implementation of IHttpHandler (even if that handler ultimately forms a Web page based on your ASP.NET Web Forms code).

HTTP handlers live for a very short period of time. They stick around long enough to handle a request, and then they disappear. For very simple applications, this model might be just fine. However, imagine the requirements of even a modest commercial-grade application. If all you had to work with was these ephemeral handlers, you’d have no way to achieve applicationwide functionality. For example, imagine you wanted to cache data to avoid round-trips to the database. You’d need to store that data in a place where all the HTTP handlers could get to it. The HttpApplication class exists for that purpose—to act as a rendezvous point for your request processing. During the lifetime of a Web application, the HttpApplication objects serve as places to hold application-wide data and handle application-side events.

The HttpContext

The HttpContext class acts as a central location in which you can access parts of the current request as it travels through the pipeline; In fact, every aspect of the current request is available through HttpContext. Even though the HttpContext components are really just references to other parts of the pipeline, having them available in a single place makes it much easier to manage the request.

Here is an abbreviated listing of HttpContext, showing the parts you’ll be using most frequently in developing Web applications. The members are exposed as properties.

class HttpContext


public static HttpContext Current {…};

public HttpRequest Request {…};

public HttpResponse Response {…};

public HttpSessionState Session {…};

public HttpServerUtility Server {…};

public HttpApplicationState Application {…};

public HttpApplication ApplicationInstance {…};

public IDictionary Items {…};

public IPrincipal User {…};

public IHttpHandler CurrentHandler {…};

public Cache Cache {…};


The static Current property gives you a means of getting to the current request at any time. Many times, the HttpContext is passed as a method parameter (as in the method IHttpHandler.RequestProcess(HttpContext ctx)); however, there may be times when you need the context even though it hasn’t been passed as a parameter. The Current property lets you grab the current process out of thin air. For example, this is how you might use HttpContext.Current:

Public void DealWithRequest()


HttpContext thisRequest = HttpContext.Current;

thisRequest.Response.Write(“<h3> Hello World</h3>”);


As you can see from the previous snippet of the HttpContext object, the properties within HttpContext include such nuggets as

  • A reference to the context’s Response object (so you can send output to the client)
  • A  reference to the Request object (so you can fi nd information about the request itself)
  • A reference to the central application itself (so you can get to the application state)
  • A reference to a per-request dictionary (for storing items for the duration of a request)
  • A reference to the application-wide cache (to store data and avoid round-trips to the database)

We’ll be seeing a lot more of the context—especially when we look at writing a custom HttpHandler.


While the Application object is suitable for handling application-wide events and data on a small scale, sometimes application-wide tasks need a little heavier machinery. HttpModules serve that purpose.

ASP.NET includes a number of predefined HttpModules. For example, session state, authentication, and authorization are handled via HttpModules. Writing HttpModules is pretty straightforward and is a great way to handle complex application-wide operations. For example, if you wanted to write some custom processing that occurs before each request, using HttpModules is a good way to do it. We’ll see HttpModules up close later.


The last stop a request makes in the pipeline is an HttpHandler. Any class implementing the interface IHttpHandler qualifies as a handler. When a request finally reaches the end of the pipeline, ASP.NET consults the configuration file to see if the particular file extension is mapped to an HttpHandler. If it is, the ASP.NET loads the handler and calls the handler’s IHttpHandler.ProcessRequest method to execute the request.

Visual Studio and ASP.NET

Visual Studio .NET 2008 expands your options for locating your Web sites during development. The Visual Studio .NET 2008 wizards define four separate Web site projects: local IIS Web sites, file system–based Web sites, FTP Web sites, and remote Web sites.

Here’s a rundown of the different types of Web sites available using the project wizard. Each is useful for a particular scenario, and having these options makes it much easier to develop and deploy an ASP.NET application with Visual Studio 2008 than with earlier versions.

Local IIS Web Sites

Creating a local IIS Web site is much like creating a Web site using the older versions of Visual Studio .NET specifying a local virtual directory. This option creates sites that run using IIS installed on your local computer. Local IIS Web sites store the pages and folders in the IIS default directory structure (that is, \Inetpub\wwwroot). By default, Visual Studio creates a virtual directory under IIS. However, you may create a virtual directory ahead of time and store the code for your Web site in any folder. The virtual directory just needs to point to that location.

One reason to create a local Web site is to test your application against a local version of IIS, for example, if you need to test such features as application pooling, ISAPI filters, or HTTPbased authentication. Even though a site is accessible from other computers, it’s often much easier to test these aspects of your application when you can see it interact with IIS on your computer. To create a local Web site, you need to have administrative rights. For most developers, this is not an issue.

File System–Based Web Sites

File system–based Web sites live in any folder you specify. The folder may be on your local computer or on another computer sharing that folder. File-system Web sites do not require IIS running on your computer. Instead, you run pages by using the Visual Studio Web server.

File-system Web sites are useful for testing your site locally but independently of IIS. The most common approach is to create, develop, and test a fi le-system Web site. Then when it is time to deploy your site, simply create an IIS virtual directory on the deployment server and move the pages to that directory.

Because file-system Web sites employ the Visual Studio Web server rather than IIS, you may develop your Web site on your computer even when logged on as a user without administrative rights. This scenario is useful for developing and testing those features of your site that you develop.

Because IIS is out of the picture, you won’t be able to work with (or have to deal with) such IIS features as ISAPI filters, application pooling, or authentication (though in many cases you won’t need to worry about that sort of thing during development).

FTP Web Sites

In addition to creating HTTP-based sites, you may use Visual Studio to manage Web sites available through an FTP server. For example, if you use a remote hosting company to host your Web site, an FTP server offers a convenient way to move fi les back and forth between your development location and the hosting location.

Visual Studio connects to any FTP server for which you have read and write privileges. Once connected, you then use Visual Studio to manage the content on the remote FTP server. You would use this option to deploy your Web site to a server that lacks FrontPage 2002 Server Extensions.

Remote Web Sites

The final option for developing and managing Web sites through Visual Studio is to use the remote Web sites option. Remote Web sites use IIS on another computer that is accessible over a network. In addition to running IIS, the remote computer must have IIS installed and needs to have FrontPage 2002 Server Extensions installed. Pages and folders on a remote site become stored under the default IIS folder on the remote computer. This option is useful if you decide you want to move the Web site to its actual deployment server. In addition, the entire development team can work on the site simultaneously. The downside of this approach is that debugging and configuring a Web site remotely can sometimes be tricky because it’s slow and hard to control the site as a whole.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: