ASP.NET

Built-in Handlers

One of the best examples of custom handling is the Trace handler that is built into ASP.NET. We looked at tracing in Tutorial 16. You turn tracing on within 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 they may 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 file: Trace.axd. Take a look at Listing 18-1 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 18-1. The processing for this handler is very specific-the handler's job is to render the results of the last few requests. As you can see in Figure 18-2, selecting 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 18-3 shows the IIS file mapping for files with the .axd extension. The ISAPI extension DLL handling the request is aspnet_isapi.dll. That means IIS will pass requests for files with an extension of .axd on to ASP.NET. Once inside the ASP.NET pipeline, the Web.Config file tells ASP to handle the request with the Trace handler.

Figure 18-1 The output of the Trace.axd handler.
Figure 18-1 The output of the Trace.axd handler. Figure 18-2 The output of the Trace.axd handler when drilling down into a request summary.
Figure 18-2 The output of the Trace.axd handler when drilling down into a request summary. Figure 18-3 IIS understands files with the extension .axd.
Figure 18-3 IIS understands files with the extension .axd.

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

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

Remember that ASP.NET's configuration is very malleable and that you may choose to let clients see your source code by one of two means. You may remove the source code extension to ASP.NET mappings within IIS. Alternatively, you may 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. Let's take a look at this key interface.