Programming Microsoft ASP.NET 4 - Dino Esposito [88]
Any request that belongs to a route managed by a StopRoutingHandler object is processed as a plain ASP.NET Web Forms endpoint. The following code instructs the routing system to ignore any .axd requests:
// In global.asax.cs
protected void Application_Start(Object sender, EventArgs e)
{
RegisterRoutes(RouteTable.Routes);
}
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
...
}
All that IgnoreRoute does is associate a StopRoutingHandler route handler to the route built around the specified URL pattern, thus preventing all matching URLs from being processed.
A little explanation is required for the {*pathInfo} placeholder in the URL. The token pathInfo simply represents a placeholder for any content following the .axd URL. The asterisk (*), though, indicates that the last parameter should match the rest of the URL. In other words, anything that follows the .axd extension goes into the pathInfo parameter. Such parameters are referred to as catch-all parameters.
Note
Earlier in this chapter, I presented HTTP handlers as a way to define your own commands for the application through customized URLs. So what’s the difference between HTTP handlers and URL routing? In ASP.NET, HTTP handlers remain the only way to process requests; URL routing is an intermediate layer that pre-processes requests and determines the HTTP handler for them. In doing so, the routing module decides whether the URL meets the expectations of the application or not. In a nutshell, URL routing offers a more flexible and extensible API; if you just need one specially formatted URL, though, a direct HTTP handler is probably a simpler choice.
Summary
HTTP handlers and HTTP modules are the building blocks of the ASP.NET platform. ASP.NET includes several predefined handlers and HTTP modules, but developers can write handlers and modules of their own to perform a variety of tasks. HTTP handlers, in particular, are faster than ordinary Web pages and can be used in all circumstances in which you don’t need state maintenance and postback events. To generate images dynamically on the server, for example, an HTTP handler is more efficient than a page.
Everything that occurs under the hood of the ASP.NET runtime environment occurs because of HTTP handlers. When you invoke a Web page or an ASP.NET Web service method, an appropriate HTTP handler gets into the game and serves your request.
HTTP modules are good at performing a number of low-level tasks for which tight interaction and integration with the request/response mechanism is a critical factor. Modules are sort of interceptors that you can place along an HTTP packet’s path, from the Web server to the ASP.NET runtime and back. Modules have read and write capabilities, and they can filter and modify the contents of both inbound and outbound requests.
In ASP.NET 4, a special HTTP module has been introduced to simplify the management of application URLs and make the whole process more powerful. The URL routing HTTP module offers a programmer-friendly API to define URL patterns, and it automatically blocks calls for nonmatching URLs and redirects matching URLs to specific pages. It’s not much different from old-fashioned URL rewriting, but it offers a greater level of control to the programmer.
With this chapter, our exploration of the ASP.NET and IIS runtime environment terminates. With the next chapter, we’ll begin a tour of the ASP.NET page-related features.
Part II. ASP.NET Pages and Server Controls
In this part:
Chapter 5
Chapter 6
Chapter 7
Chapter 8
Chapter 9
Chapter 10
Chapter 11
Chapter 12
Chapter 5. Anatomy of an ASP.NET Page
The wise are instructed by reason; ordinary minds by experience; the stupid, by necessity; and brutes by instinct.
—Cicero
ASP.NET pages are dynamically compiled on demand when first requested in the context of a Web application. Dynamic compilation is not specific to ASP.NET pages