Solution to WebResource.axd exception

I have got several mail about how to solve the issue with the exception “The WebResource.axd handler must be registered in the configuration to process this request” that is quite common to get when you use EPiServer CMS.

My earlier hack in my blog post The mysterious problem with WebResource.axd is no longer needed since the cause is know.

Update: The cause and fix was originally found by Per Bjurstöm at EPiServer. I forgot to give him credit for this! Sorry.

Update: I think the documentation is a little bit confusing since it states: “The <add> directives are processed in top-down, sequential order. If two or more <add> subdirectives specify the same verb/path combination, the final <add> overrides all others”. Final should be interpreted as the one on top of the list. Values inherited from parent folders, the application web.config and machine web.config are at the bottom if the list – That is why path=”*” is so dangerous since it hides everything.

Summary and solution

The reason you get the WebResource.axd exception is that you (or in the case with EPiServer it is there as default) have added http handlers with wild card mapping to your web.config.

ASP.NET processes http handlers in the reverse order they are added so when a you add a wildcard mapping at the end it will effectively hide the WebResoruce handler.

To solve the issue: Add one line before each wild card mapping to re-register the http handler for WebResources like this:

<location path="PageFiles">
  <system.web>
    <httpHandlers> 
     <add path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" validate="True"/> 
      <add path="*" verb="GET,HEAD" type="EPiServer.Web.StaticFileHandler, EPiServer" validate="true"/>  
    </httpHandlers>
  </system.web>
</location>

Bookmark and Share
  1. Per Bjurström’s avatar

    I added the WebResource.axd line before the wildcard mapping and it worked also, does order really matter here ?

    http://labs.episerver.com/en/Blogs/Per/Archive/2008/5/The-not-so-mysterious-problem-with-WebResourceaxd/

    Reply

  2. Fredrik Haglund’s avatar

    Hi Per!
    Yes, the order is important and I mixed it up because I read the not so clear msdn documentation. Thanks for correcting me!
    /Fredrik

    Reply

  3. Mattias’s avatar

    Good thing I read this post yesterday, since a customers live site got this problem this morning. So, thanks a lot!

    What confuses me is why we got the problem now, after running the site for almost a month (no changes in web.config since the release).
    The only change that has been made is an update of our Customer.dll (and only that file), which was made yesterday. But we tested the site after the update, and without any problems.

    So the question is if these events are even related, and if they are – why did it take several hours before it showed up?

    Reply

  4. Fredrik Haglund’s avatar

    Mattias, the problem was hard to reproduce because it only occurs if you access an uploaded file (in one of the virtual file systems handled by EPiServers File Manager) as first call after the app is started.

    This can happend if you recycle the application pool or do an iisreset while you have traffic to the site.

    So, you need some bad luck before it is triggered…

    Per told me this is fixed in the upcoming release of EPiServer 5 R2.

    Reply

  5. Andreas Ek’s avatar

    Just great! At last!

    I really would like EPiServer to publish this solution at their first news page at world-pages… Important news!

    Reply

  6. milan mathew’s avatar

    Yes… It works. recently i changed the order of .axd.

    Thanks guys…

    Reply