HttpHandler and HttpModule in Real Scenario: Getting Started With HttpHandler

This is our first presentation of the “HttpHandler and HttpModule in real scenario” article series. Before starting with the technical discussion let’s clarify the purpose of this series.

As the name implies, we will understand a few scenarios where we can implement the concept of HttpHandler in our ASP.NET application. So, the series is not targeting those who are very new to this concept. After following this series you may get the following benefits:

• Basic implementation of HttpHandler and HttpModule
• Good understanding of HttpHandler and HttpModule of ASP.NET request processing pipeline
• Understanding of real problem where we can use both

Since this series will emphasize practical examples, we will not discuss the theoretical parts of HttpHandler and HttpModule. I recommend the use of MSDN for that. In the first few articles we will cover HttpHandler and then we will get to HttpModule with practical examples.

We know that HttpHandler is responsible for handling each and every HTTP request (from 10K feet above) and ASP.NET uses various HTTP handlers to serve the various file types. For example, the handler for a web page takes a HTTP request targeted to some .aspx or .html page and processes the request.

That’s fine; ASP.NET uses HttpHandler to process a HTTP request, but why do we need to create our own HttpHandler?

If we don’t satisfy the job requirements with the default HttpHandler of ASP.NET then we need to create our own. And in this example we will create our own HttpHandler that will be injected into a HTTP request processing pipeline.

Here are a few reasons to create our own HttpHandler:

1. Implement security features
2. Dynamic image generation
3. Create RSS feed and binary data

And many more.

Ok, so let’s start to implement our first HttpHandler in ASP.NET applications. Let’s think that, for maintenance purposes, our site must be down for a few hours and we want to show some default message to our visitors and we want to solve this problem using HttpHandler.

This could be one scenario where we can implement HttpHandler , because before processing to any request we wants to show some custom message to user and we will drop any request for .aspx file.

So, this is the scenario and let’s start the implementation.

Create one empty Web Form application and add one Handler (.ashx) file to that, as in the following.



In this example I am keeping a filename as Handler.ashx that could be more relevant depending on the purpose of Handler.

Here is the code of the Handler1.ashx file. The ProcessRequest() function will execute in each and every HTTP request and the most interesting encounter that the HTTP request will not move to the next pipeline because we are creating a HTTP response within the ProcessRequest() function that will bypass all the steps of HTTP request steps in the ASP.NET application.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Web;

 

namespace WebApp

{

    public class ShutdownHandler : IHttpHandler

    {

        public void ProcessRequest(HttpContext context)

        {

            context.Response.ContentType = "text/plain";

            context.Response.Write("Currently we are down for mantainance");

        }

 

        public bool IsReusable

        {

            get

            {

                return false;

            }

        }

    }

}

Here we have successfully created our first HttpHandler and now we need to resister it in the ASP.NET request processing pipeline. Open the web.config file of the application and add the following code into it.

</system.webServer>
<handlers>
    <add name="myHandler" verb="*" path="*.aspx" type="WebApp.ShutdownHandler"/>
   </handlers>
</system.webServer>

Within the <handler> tag we are registering our newly created HttpHandler . The purpose of this handler is, when a request is received targeting an .aspx file the handler will be executed and it will drop the HTTP request, thereby generating a response immediately. Let’s discuss the line a little bit.

Name: This is a property of the add tag to identify the add tag uniquely. It’s nothing but a simple name of the registration process.
Varb: It indicates the HTTP verb/s, for which we want to execute the HttpHandler. Here we have used “*”, in other words it will execute for all types of HTTP verbs.
Path: This implies the request path of the HTTP resource. In our example we have kept “*.aspx”; that implies any .aspx file without depending on filename or file path.
Type: This property implies the class location of HttpHandle.

Now, if we run our application and if we request an .aspx page then we will see the following output screen.

Cheers! We have successfully run the first example of HttpHandler. The advantage of using HttpHandle in this scenario is that we are not allowing the HTTP request to be processed further so the request is not reaching the page level and that is saving a lot of server resources.

Let’s stop the image service in the application

To implement this scenario we will modify the previous example a little bit.

First change the path property of the HttpHandler registration in the web.config file. Here we have set the path value to “*.jpg” as in the following:

<add name="myImageHandler" verb="*" path="*.jpg" type="WebApp.ShutdownHandler"/>

In other words, if any request comes by targeting any .jpg file then the request will be handled by our custom HttpHandler.

Here is a modified version of the previous ProcessRequest() method. We did not make any change except the output message.

public void ProcessRequest(HttpContext context)

{

       context.Response.ContentType = "text/plain";

       context.Response.Write("Currently we are not serving Image file");
 }

Now if we request the application for any image file as in the following then we will get our custom message.



Though, the example is very similar to the previous example but we have learned that not only the .aspx/.html file , we can restrict any type of file using HttpHandler with our custom logic.

Conclusion

This is the first and simplest example of HttpHandler in this article series. Here we have seen how to implement our custom logic in the middle of the ASP.NET HTTP request processing pipeline with an example.

I hope you have understood it and in the future article we will see a few more real-life scenarios and it’s a solution by HttpHandler and HttpModule.