Why does ASP.NET Routing take precendence over web.config Http Handlers section?

Question

Our shop is integrating ASP.NET MVC into a large web application that utilizes custom & 3rd party HTTP Handlers defined in web.config under system.webServer\handlers. Leveraging HTTP Handlers in this way has been great for us because we don't need to recompile the app or have the actual handler page sitting on disk somewhere in the web scope for each instance of the product.

Is it really necessary to add explicit Ignore Routes in our global.asax so the Runtime can honor our Handlers defined in web.config? I would have thought Web.Routing would be invoked after the handlers defined in system.webServer\handlers have been checked (not the other way around).

We use a modular design that allows adding/dropping Handlers from web.config when features are added. With the introduction of MVC routing it appears we need to add ignore routes in the global.asax file for every possible handler defined in web.config.

Note the actual file to these Handlers don't exist on disk - they are virtual and embedded in an assembly. Here's an example of a 3rd party handler that now requires an explicit Ignore Route in global.asax:

<system.webServer>
    <handlers>
          <!-- telerik radcontrols -->
          <add name="TelerikDialogHandler" verb="*" path="Telerik.Web.UI.DialogHandler.aspx" type="Telerik.Web.UI.DialogHandler, Telerik.Web.UI, Version=2009.1.402.20, Culture=neutral, PublicKeyToken=121fae78165ba3d4"></add>
    </handlers>
</system.webServer>

So for the record if you use System.Web.Routing you must include Ignore Routes for Http Handlers specified in Web.Config? Or perhaps I'm doing something wrong?

Answer 1

ASP.NET request processing is based on a pipeline model in which ASP.NET passes http requests to all the modules in the pipeline. Each module receives the http request and has full control over it. Once the request passes through all of the HTTP modules, it is eventually processed by an HTTP handler. The HTTP handler performs some processing on it, and the result again passes through the HTTP modules in the pipeline.

I think that the best way to think about these is that HttpModule is a filter that adds or subtracts something from the request object when an event occurs and the HttpHandler is a processor that actually serves the request. The ASP.NET request lifecycle is setup in such a way that all filters are applied to the request first before processing occurs.