Question

Using the following steps:

(I have checked this similar post, which does not solve my problem.)

1. Under Windows Server 2003/IIS6, I create a new site called “testapp”
2. In VS2010, I create a new ASP.NET MVC 2 application.

3. I add a view called “Info” with the following code:

   <h2>System</h2>
   
   <h3>Request</h3>
   
   <%
       foreach (string key in Request.Headers)
       {
           Response.Write(string.Format("<p>{0}={1}</p>"
                   , key
                   , Request.Headers[key])
                   );
       }
   
   
   %>
   

In addition to the standard headers I see this one:

   X-REWRITE-URL=/home/info/eurl.axd/e3299f29f8043d4f8a27e0f1d0c40971

I am using Helicon ISAPI Rewrite 3, which is generating the “X-REWRITE-URL” header.

My problem is this: where is the /eurl.axd?.... coming from? I’ve seen this article, but since this is a blank app in a new folder with a new app pool, there are NO 2.0.* apps running within this web folder. There are no virtual folders pointing at another directory, etc. The site is configured for ASP.NET 4.0, which is registered correctly.

The problem is that the eurl.axd is screwing with parameters in my MVC routes.

The options in the “ASP.NET 4.0 Breaking Changes” article don’t really work for me, because there aren’t any 2.0 components in this app, and I need to use extensionless URLs.

Update I’ve just noticed that System.Web.MVC in the GAC is version 2.0.0.0. Should this have been updated to 4.0 with the installation of VS2010 and the 4.0 framework?

I don’t understand why I’m seeing this error with a default ASP.NET MVC 2 application. Help!!

Update 2/2011 – Resolved

Having finally tried disabling extensionless URLs via the registry hack, the problem disappeared. I find it counter-intuitive that disabling extensionless URLs makes extensionless URLs work (with the wildcard mapping in IIS6), but I’ll take what I can get.

Update 12/2014

(Merry|Happy|Peaceful) (Christmas|Hanukkah|Kwanzaa|December).

I forgot to mention that every other Windows update nuked the registry change. This appeared as weird problems where a request to http://site.dom/bob would fail, while http://site.dom/bob/ would succeed. Have fun! (Notice the trailing slash.)

Answer 1

This is part of Microsoft’s approach to enable extensionless URLs to be handled by ASP.NET v4 by default in IIS 6. It is described here in the ASPNET V4 Breaking Changes document. (Search in that document for eurl.axd). This happens only with ASPNET v4.

What happens is:

1. aspnet_filter.dll, the global ISAPI filter that implements ASPNET (right-click Web Sites folder > Properties to see it) inspects each incoming url. For those urls that have no extension, ASPNET then mangles the URL to insert /eurl.axd/some-long-number into it. Actually the long number is a guid with no dashes.

2. Your URL rewriter, a site-specific ISAPI filter, runs next and sees the mangled URL. Because your rules don’t expect URLs with that odd sequence injected into them, your rewrite filter doesn’t handle it properly, and the user probably ends up with a 404.

This will happen with any rewrite filter – Helicon ISAPI_Rewrite, IIRF, etc. – when installed with IIS6 and ASPNET v4. It may also happen with other ISAPI filters – those that are not explicitly rewriters.

What Microsoft intended to happen:

1. aspnet_filter.dll ISAPI filter adds /eurl.axd/some-long-number to an extensionless URL. (If the URL has an extension in it, it leaves it alone, saving performance hit from hitting managed code.) This is just to get “.axd” in there so IIS6, in its default configuration, will map to the aspnet_isapi.dll ISAPI extension (application).

2. The aspnet_isapi.dll ISAPI application picks up the request, unmangles the URL by removing the /eurl.axd/some-long-number, and passes it to the ASP.NET code designed to handle extensionlesses URLs. That code handles the request and does not realize that the /eurl.axd/some-long-number shenanigans ever happened.

Microsoft failed to consider what would happen for URL-inspecting ISAPI filters that sit between steps 1 and 2. The ASP.NET 4 release notes have a note about .NET 2.0 applications causing this error; that’s just one way it can happen.

You have some options:

• Use the registry key to just turn it off. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0 > DWORD EnableExtensionlessUrls to 0 , then restart IIS.

• Do URL rewriting within the ASP.NET pipeline. (Obviously you can only rewrite managed requests in this case.)

• Install your ISAPI filter URL rewriter at the global level at a priority higher than aspnet_filter.dll. Sounds like a pain to me.

• Configure the Website to use ASPNET v2, rather than ASPNET v4.

• insert a rule in your rewriter to completely ignore URLs with eurl.axd in them. This might be as simple as
  RewriteRule eurl\.axd -

I use the registry key and it works fine for me.

Good luck!

UPDATE 2011-08-10: It appears that Windows Updates that service the .NET Framework reset the registry key, and it has to be reapplied.

Edit 2012-02-17 We had this problem and our team spent several hours working the problem before someone found this buried in the comments completed the solution for us. “Note that for Wow64 (i.e., 32-bit worker process running on 64-bit OS), this registry key must be set at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ASP.NET\4.0.30319.0\EnableExte‌​nsionlessUrls.”