Programming Microsoft ASP.NET 4 - Dino Esposito [69]
In classic mode, instead, two distinct pipelines exist in IIS and ASP.NET. The extension, in this case, is mandatory to instruct IIS to recognize that request and map it to ASP.NET, where the HTTP handler actually lives. As an example, consider that when you deploy ASP.NET MVC in classic mode you have to tweak URLs so that each controller name has an .mvc suffix. To force IIS to recognize a new resource, you must add a new script map via the IIS Manager, as shown in Figure 4-2.
Figure 4-2. Adding an IIS script map for .report requests.
The executable is the ISAPI extension that will be bridging the request from the IIS world to the ASP.NET space. You choose the aspnet_isapi DLL from the folder that points to the version of the .NET Framework you intend to target. In Figure 4-2, you see the path for ASP.NET 4.
Note
In Microsoft Visual Studio, if you test a sample .report resource using the local embedded Web server, nothing happens that forces you to register the .report resource with IIS. This is just the point, though. You’re not using IIS! In other words, if you use the local Web server, you have no need to touch IIS; you do need to register any custom resource you plan to use with IIS before you get to production.
Why didn’t we have to do anything special for our first example, hello.axd? Because AXD is a system extension that ASP.NET registers on its own and that sometimes also can be used for registering custom HTTP handlers. (AXD is not the recommended extension for custom handlers, however.)
Now let’s consider a more complex example of an HTTP handler.
The Picture Viewer Handler
To speed up processing, IIS claims the right to personally serve some typical Web resources without going down to any particular ISAPI extensions. The list of resources served directly by IIS includes static files such as images and HTML files.
What if you request a GIF or a JPG file directly from the address bar of the browser? IIS retrieves the specified resource, sets the proper content type on the response buffer, and writes out the bytes of the file. As a result, you’ll see the image in the browser’s page. So far so good.
What if you point your browser to a virtual folder that contains images? In this case, IIS doesn’t distinguish the contents of the folder and returns a list of files, as shown in Figure 4-3.
Figure 4-3. The standard IIS-provided view of a folder.
Wouldn’t it be nice if you could get a preview of the contained pictures instead?
Designing the HTTP Handler
To start out, you need to decide how to let IIS know about your wishes. You can use a particular endpoint that, when appended to a folder’s name, convinces IIS to yield to ASP.NET and provide a preview of contained images. Put another way, the idea is to bind your picture viewer handler to a particular endpoint—say, folder.axd. As mentioned earlier in the chapter, a fixed endpoint for handlers doesn’t have to be an existing, deployed resource. You make the folder.axd endpoint follow the folder name, as shown here:
http://www.contoso.com/images/folder.axd
The handler processes the URL, extracts the folder name, and selects all the contained pictures.
Note
In ASP.NET, the .axd extension is commonly used for endpoints referencing a special service. Trace.axd for tracing and WebResource.axd for script and resources injection are examples of two popular uses of the extension. In particular, the Trace.axd handler implements the same logic described here. If you append its name to the URL, it will trace all requests for pages in that application.
Implementing the HTTP Handler
The picture viewer handler returns a page composed of a multirow table showing as many images as there are in the folder. Here’s the skeleton of the class:
class PictureViewerInfo
{
public PictureViewerInfo() {
DisplayWidth = 200;
ColumnCount = 3;
}
public int DisplayWidth;
public int ColumnCount;
public