views:

259

answers:

1

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 can't 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!!

A: 

This is part of Microsoft's lame attempt to enable extensionless URLs to be handled by ASP.NET by default in IIS 6.

  1. aspnet_filter.dll (global ISAPI filter, right-click Web Sites folder > Properties to see it) executes and mangles the URL to add /eurl.axd/some-long-number to it

  2. Your URL rewriter (a site-specific ISAPI filter) runs next and sees the insane URL, your rewrite rule does something strange, you probably end up with a 404

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 application.

  2. The aspnet_isapi.dll ISAPI application picks up the request, unmangles the URL by removing the /eurl.axd/some-long-number crap, and the ASP.NET code that handles the request 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 red herring 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. (This is what I do and it works fine.) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0 > DWORD EnableExtensionlessUrls to 0 > restart the machine

  • 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.

My advice? Use the registry key. Good luck!

Nicholas Piasecki