Unable to map an HttpHandler to a "path/*" wildcard mapping Unable to map an HttpHandler to a "path/*" wildcard mapping asp.net asp.net

Unable to map an HttpHandler to a "path/*" wildcard mapping


Simple. Just put the path, no wildcard.

<handlers>  <add name="Nancy" path="api" verb="*" type="Nancy.Hosting.Aspnet.NancyHttpRequestHandler" allowPathInfo="true" /></handlers>

This will match:

/api/{anything}


The URLRoutingModule-4.0 is a catch all handler listed before your nancy handler. It will thus come into play before your handler is ever hit. You can remove the handlers add yours and add them back in like so:

<handlers>    <remove name="BlockViewHandler" />    <remove name="UrlRoutingModule-4.0" />    <add verb="*" path="robots.txt" name="robots" type="System.Web.StaticFileHandler"/>    ... custom handlers here    <add name="Nancy" path="api/*" verb="*" type="Nancy.Hosting.Aspnet.NancyHttpRequestHandler" allowPathInfo="true" />    ... now add back UrlRoutingModule and BlockViewHandler    <add path="*" verb="*" name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" preCondition="managedHandler" />    <add name="BlockViewHandler" path="*" verb="*" preCondition="integratedMode" type="System.Web.HttpNotFoundHandler" /> </handlers>

You can see the handler order in IIS7 under Handler Mappings select View Ordered List and it will list the order in which it loads the handlers top (first) to bottom (last).

You might need a second Web.config in your /api folder

<?xml version="1.0"?><configuration>    <system.web>      <httpHandlers>        <clear />        <add name="Nancy" path="*" verb="*" type="Nancy.Hosting.Aspnet.NancyHttpRequestHandler" allowPathInfo="true" />      </httpHandlers>    </system.web></configuration>

Similarly, this is what I usually do for "/static" content on websites. I have not found out how to circumvent the need for the seconds web.config.

EDIT

I had a hard time figuring this out when i had to as well and it seems my memory hasnt served me well. I dont specify a path/* handler anywhere instead I have this:

(only specifying simple wildcards/fully qualified paths to go around UrlRouting)

<location path="." inheritInChildApplications="false">    <system.webServer>        <!--        ml: in .NET 4.0 its now safe to remove  from the modules section.        Make sure you have a *. mapping to a ExtensionLessUrl hanlder in IIS        this should improve performance a tad albeit neglectable.        see: http://blogs.msdn.com/b/tmarq/archive/2010/04/01/asp-net-4-0-enables-routing-of-extensionless-urls-without-impacting-static-requests.aspx        -->        <validation validateIntegratedModeConfiguration="false" />        <modules runAllManagedModulesForAllRequests="false" />        <handlers>            <remove name="BlockViewHandler" />            <remove name="UrlRoutingModule-4.0" />            <add verb="*" path="robots.txt" name="robots" type="System.Web.StaticFileHandler"/>            .. Some company handlers i can't list             <add path="*" verb="*" name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" preCondition="managedHandler" />            <add name="BlockViewHandler" path="*" verb="*" preCondition="integratedMode" type="System.Web.HttpNotFoundHandler" />        </handlers>    </system.webServer></location>

Then in my /Content/web.config file I set the following:

<?xml version="1.0" encoding="UTF-8"?><configuration>    <system.webServer>        <handlers>            <clear />            <add name="StaticFiles" path="*" verb="*" modules="StaticFileModule" resourceType="Either" requireAccess="None" />        </handlers>        <staticContent>            <clientCache cacheControlMaxAge ="31.00:00:00" cacheControlMode="UseMaxAge" />        </staticContent>    </system.webServer></configuration>

My handler list for /Content/ looks like this now:

Handler list

Which is about as sure as I can be anything in /Content/ will be served through StaticFileModule. The trick here seems to be specifying: inheritInChildApplications="false".


Seems the UrlRoutingModule-4.0 is more trouble than it is worth. Instead I've just told MVC3 to ignore the routes. Not a perfect solution but until I have something that works better I'll have to stick with this in RegisterRoutes:

routes.IgnoreRoute("api/{*route}");