asp.net-mvc - ASP.NET MVC eurl.axd错误

Question

使用以下步骤:

(我检查了this similar post，它不能解决我的问题。)

在Windows Server 2003 / IIS6下，我创建了一个名为“testapp”的新站点

在VS2010中，我创建了一个新的ASP.NET MVC 2应用程序。

我使用以下代码添加一个名为“Info”的 View :

<h2>System</h2>

<h3>Request</h3>

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


%>

除了标准标题外，我还看到了以下内容:

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

我正在使用Helicon ISAPI Rewrite 3，它正在生成“X-REWRITE-URL” header 。

我的问题是:/eurl.axd?....来自哪里？我见过this article，但是由于这是带有新应用程序池的新文件夹中的空白应用程序，因此此Web文件夹中没有运行2.0。*应用程序。没有虚拟文件夹指向另一个目录，等等。该站点配置为ASP.NET 4.0，它已正确注册。

问题是eurl.axd与我的MVC路由中的参数搞混了。

“ASP.NET 4.0重大更改”文章中的选项对我而言并不真正有效，因为此应用程序中没有任何2.0组件，因此我需要使用无扩展名的URL。

更新我刚刚注意到GAC中的System.Web.MVC是2.0.0.0版。是否应该通过安装VS2010和4.0框架将其更新到4.0？

我不明白为什么默认ASP.NET MVC 2应用程序会出现此错误。救命!!

更新2/2011-已解决

最终尝试通过注册表黑客禁用无扩展名的URL之后，问题消失了。我发现禁用无扩展名URL使无扩展名URL起作用(与IIS6中的通配符映射一起使用)是违反直觉的，但是我会尽力而为。

更新12/2014

(快乐|快乐|和平)(圣诞节|光明节|宽扎|十二月)。

我忘了提到其他所有Windows更新都破坏了注册表更改。这似乎是奇怪的问题，其中对http://site.dom/bob的请求将失败，而http://site.dom/bob/的请求将成功。玩得开心! (注意尾随斜杠。)

Answer 1

这是Microsoft启用IIS 6中默认情况下由ASP.NET v4处理无扩展名URL的方法的一部分。在ASPNET V4 Breaking Changes文档中对此进行了描述。 (在该文档中搜索eurl.axd)。仅在ASPNET v4中会发生这种情况。

发生的是:

aspnet_filter.dll，实现ASPNET的全局ISAPI筛选器(右键单击“网站文件夹”>“属性”以查看它)检查每个传入的URL。对于那些没有扩展名的URL，ASPNET然后会对URL进行修饰以在其中插入/eurl.axd/some-long-number。实际上，长数字是没有破折号的GUID。

您的URL重写器是一个特定于站点的ISAPI筛选器，接下来将运行并查看错误的URL。因为您的规则不希望URL带有插入的那个奇数序列，所以您的重写过滤器无法正确处理它，并且用户可能最终得到404。

与IIS6和ASPNET v4一起安装时，任何重写筛选器(Helicon ISAPI_Rewrite，IIRF等)都会发生这种情况。其他ISAPI筛选器(未明确重写的筛选器)也可能发生这种情况。

微软打算发生的事情:

aspnet_filter.dll ISAPI筛选器将/eurl.axd/some-long-number添加到无扩展名的URL。 (如果URL中具有扩展名，则将其保留下来，以免由于击中托管代码而导致性能下降。)这仅仅是为了在其中获得“.axd”，因此IIS6在其默认配置下将映射到aspnet_isapi.dll ISAPI扩展名(应用)。

aspnet_isapi.dll ISAPI应用程序接收请求，通过删除/eurl.axd/some-long-number取消对URL的破坏，并将其传递给旨在处理无扩展名URL的ASP.NET代码。该代码处理该请求，并且没有意识到/eurl.axd/some-long-number恶作剧曾经发生过。

Microsoft无法考虑位于步骤1和步骤2之间的URL检查ISAPI筛选器将发生什么。ASP.NET 4发行说明中有一个有关导致此错误的.NET 2.0应用程序的说明；请参阅引用。那只是它发生的一种方式。

您有一些选择:

使用注册表项将其关闭。 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0> DWORD EnableExtensionlessUrls到0，然后重新启动IIS。

在ASP.NET管道中执行URL重写。 (显然，在这种情况下，您只能重写托管请求。)

在全局级别以高于aspnet_filter.dll的优先级安装ISAPI筛选器URL重写器。对我来说听起来很痛苦。

配置网站以使用ASPNET v2，而不是ASPNET v4。

在您的重写器中插入一条规则，以完全忽略其中包含eurl.axd的URL。这可能很简单
RewriteRule eurl\.axd -

我使用注册表项，对我来说很好。

祝好运!

UPDATE 2011-08-10:看来，为.NET Framework服务的Windows Update重置了注册表项，因此必须重新应用它。

编辑2012-02-17 我们遇到了这个问题，我们的团队花了几个小时解决这个问题，然后才发现有人埋在注释中，为我们完成了解决方案。 “请注意，对于Wow64(即在64位OS上运行的32位工作进程)，此注册表项必须设置在HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ ASP.NET \ 4.0.30319.0 \ EnableExteUnsionlessUrls。”