ASP.NET MVC eurl.axd 错误

Question

使用以下步骤：

（我检查了this similar post，并没有解决我的问题。）

1. 在 Windows Server 2003/IIS6 下，我创建了一个名为“testapp”的新站点
2. 在 VS2010 中，我创建了一个新的 ASP.NET MVC 2 应用程序。

3. 我使用以下代码添加了一个名为“Info”的视图：

   <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”标头。

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

问题是 eurl.axd 在我的 MVC 路由中使用了参数。

“ASP.NET 4.0 Breaking Changes”文章中的选项对我来说并不适用，因为这个应用程序中没有任何 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 中的通配符映射）是违反直觉的，但我会尽我所能。

2014 年 12 月更新

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

我忘了提到所有其他 Windows 更新都会导致注册表更改。这似乎是一个奇怪的问题，对http://site.dom/bob 的请求会失败，而http://site.dom/bob/ 会成功。玩得开心！ （注意尾部的斜线。）

Answer 1

这是微软在 IIS 6 中默认启用 ASP.NET v4 处理无扩展 URL 的方法的一部分。ASPNET V4 Breaking Changes 文档中对此进行了描述。 （在该文档中搜索 eurl.axd）。这只发生在 ASPNET v4 上。

会发生什么：

1. aspnet_filter.dll，实现 ASPNET 的全局 ISAPI 过滤器（右键单击网站文件夹 > 属性以查看它）检查每个传入的 url。对于那些没有扩展名的 URL，ASPNET 会破坏 URL 以将 /eurl.axd/some-long-number 插入其中。实际上，长数字是一个没有破折号的 guid。

2. 您的 URL 重写器，一个特定于站点的 ISAPI 过滤器，接下来会运行并看到损坏的 URL。因为您的规则不希望 URL 注入具有奇怪序列的 URL，所以您的重写过滤器无法正确处理它，并且用户可能最终得到 404。

当与 IIS6 和 ASPNET v4 一起安装时，任何重写过滤器都会发生这种情况 - Helicon ISAPI_Rewrite、IIRF 等。其他 ISAPI 过滤器也可能发生这种情况 - 那些不是明确重写的。

微软打算发生什么：

1. aspnet_filter.dll ISAPI filter 将 /eurl.axd/some-long-number 添加到无扩展名 URL。 （如果 URL 中包含扩展名，则将其单独放置，从而节省因访问托管代码而造成的性能损失。）这只是为了在其中获取“.axd”，因此 IIS6 在其默认配置中将映射到 aspnet_isapi.dll ISAPI 扩展（应用程序）。

2. 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 重写。 （显然，在这种情况下您只能重写托管请求。）

• 在全局级别安装您的 ISAPI 过滤器 URL 重写器，优先级高于 aspnet_filter.dll。听起来对我来说很痛苦。

• 将网站配置为使用 ASPNET v2，而不是 ASPNET v4。

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

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

祝你好运！

2011-08-10 更新：似乎为 .NET Framework 提供服务的 Windows 更新重置了注册表项，并且必须重新应用。

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

Answer 2

我遇到了类似的问题，并通过我们的 ISAPI 重写模块提供程序找到了解决方案。我记录了发现和解决方案：http://www.vanadiumtech.com/OurBlog/post/2011/08/12/Cause-of-eurlaxd.aspx

Answer 3

对于在 IIS 上的 ASP.NET 4 上运行的网站，我使用以下正则表达式作为 Ionics Isapi Rewriter 的 first 规则6 解决由 ASP.NET 4 引入的breaking change 引起的问题：

RewriteRule ^(.*)/eurl.axd/[a-f0-9]{32}(.*)$ $1$2

这让我再次使用无扩展的网址。

请注意，第二组捕获查询字符串（如果存在）并将其恢复到重写的 url。

是的，它是a feature, not a bug。