Microsoft ASP.NET 4 : HTTP Handlers - The Built-in Handlers

One of the best examples of custom handling is the Trace handler built into ASP.NET. You turn tracing on in the web.config file by inserting the trace element, <trace enabled=true />. This instructs the ASP.NET runtime to store summaries of the requests going through the site so that they can be viewed for diagnostic purposes.

ASP.NET caches the tracing output in memory. To view the trace results, you surf to the virtual directory managing the site and ask for a specific resource: Trace.axd. Take a look at this Example and you'll see the first entry among all the standard HTTP handlers is for a resource named Trace.axd. The tracing functionality behind ASP.NET falls outside of normal UI processing, so it makes sense that tracing is handled by a custom handler.

When you surf to the Trace.axd resource, the handler renders HTML that looks like the output shown in Figure 1. The processing for this handler is very specific—the handler's job is to render the results of the last few requests.

Figure 1. The output of the Trace.axd handler.

As shown in Figure 2, clicking the View Details link resubmits the request with a parameter id=3 in the query string. This causes the handler to render the details of the third request.

Figure 2. The output of the Trace.axd handler focused on a specific request summary.

Figure 3 shows the Microsoft Internet Information Services (IIS) file mapping for files with the .axd extension. Although you won't really see this aspect until deployment time, it's interesting to observe because it shows how ASP.NET is very versatile in the kinds of requests it can handle. IIS handles Trace.axd requests the same way as any other ASP.NET request. That means IIS will pass requests for resources with an extension of .axd on to ASP.NET. Once inside the ASP.NET pipeline, the web.config file tells ASP.NET to handle the request with the Trace handler.

Figure 3. IIS has a handler mapping for Trace.axd.

If you look through the default web.config file a bit more, you'll see some other critical ASP.NET handlers. As you might expect, source code is banned explicitly from normal clients by default. Notice that files such as *.cs, *.config, and *.vb are handled by the Forbidden handler. If you try to look at source code in a Web browser, ASP.NET returns the page shown in Figure 4 by default.

Figure 4. What happens when you try to view forbidden content.

Remember that ASP.NET's configuration is very malleable and that you can choose to let clients see your source code by one of two means. You can remove the source code extension to ASP.NET mappings in IIS. Alternatively, you can write your own source code viewer handlers and declare them in your application's web.config file.

These handlers plug into the pipeline by implementing IHttpHandler. The next section describes this key interface.