ASP.NET MVC eurl.axd错误

Question

使用以下步骤:

(我已经检查过这个类似的帖子,这不能解决我的问题.)

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?....来自哪里？我已经看过这篇文章,但由于这是一个带有新应用程序池的新文件夹中的空白应用程序,因此在此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应用程序中看到此错误.救命!!

2011年2月更新 - 已解决

终于尝试通过注册表黑客禁用无扩展名URL,问题就消失了.我发现禁止无扩展的URL使得无扩展的URL工作(使用IIS6中的通配符映射)是违反直觉的,但我会采取我能得到的.

2014年12月更新

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

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

Answer 1

这是Microsoft在IIS 6中默认使用ASP.NET v4处理无扩展URL的方法的一部分.这将在ASPNET V4重大更改文档中进行介绍.(在该文档中搜索eurl.axd).这只发生在ASPNET v4上.

会发生什么:

1. aspnet_filter.dll,实现ASPNET的全局ISAPI筛选器(右键单击"网站"文件夹>"属性"以查看它)检查每个传入的URL.对于那些没有扩展名的网址,ASPNET /eurl.axd/some-long-number会将URL插入其中.实际上,长数是一个没有破折号的指导.

2. 您的URL重写器(特定于站点的ISAPI筛选器)将在下一个运行并查看损坏的URL.因为您的规则不希望将带有奇数序列的URL注入其中,所以您的重写过滤器无法正确处理它,并且用户最终可能会得到404.

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

微软打算发生什么:

1. aspnet_filter.dllISAPI 过滤器将/eurl.axd/some-long-number添加到无扩展名的URL.(如果URL中有一个扩展名,它会使其不受影响,从而节省了从命中托管代码中获得的性能.)这只是为了获得".axd",因此IIS6在其默认配置中将映射到aspnet_isapi.dllISAPI 扩展(应用).

2. 的aspnet_isapi.dllISAPI 应用拾取请求,通过去除unmangles的URL /eurl.axd/some-long-number,并将其传递到设计为处理extensionlesses网址ASP.NET代码.该代码处理请求,并没有意识到/eurl.axd/some-long-number shenanigans曾经发生过.

微软未能考虑在步骤1和2之间检查URL检查ISAPI过滤器会发生什么.ASP.NET 4发行说明中有关于导致此错误的.NET 2.0应用程序的注释; 这只是它可能发生的一种方式.

你有一些选择:

• 使用注册表项将其关闭. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0> DWORD EnableExtensionlessUrlsto 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我们遇到了这个问题,我们的团队花了几个小时来处理这个问题,然后有人发现这个问题已经完成了我们的解决方案."请注意,对于Wow64(即在64位操作系统上运行的32位工作进程),此注册表项必须设置为HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ASP.NET\4.0.30319.0\EnableExte nsionlessUrls."

Answer 2

我使用以下正则表达式作为第一条规则与Ionics Isapi重写器一起运行在IIS 6上的ASP.NET 4上运行的网站,以解决由ASP.NET 4引入的重大变化引起的问题:

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

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

请注意,第二个组捕获查询字符串(如果存在)并将其恢复到重写的URL.

是的,这是一个功能,而不是一个错误.