ASP.NET MVC eurl.axd错误 [英] ASP.NET MVC eurl.axd errors

问题描述

使用以下步骤进行：

（我已经检查这种类似的帖子 ，不解决我的问题。）

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

1. 在Windows Server 2003中/ IIS6，我创建了一个所谓的新网站testapp
2. 在VS2010中，我创建了一个新的ASP.NET MVC 2应用程序。

3. 我添加了一个名为信息具有以下code查看：

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

我使用赫利ISAPI重写3 ，在产生X-REWRITE-URL头。

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

我的问题是这样的：？哪里是 /eurl.axd .... 来自何处？我已经看到了<一个href="http://www.asp.net/%28S%28ywiyuluxr3qb2dfva1z5lgeg%29%29/learn/whitepapers/aspnet4/breaking-changes#0.1__Toc256770153"相对=nofollow>这篇文章，但由于这是一个新的应用程序池一个新的文件夹中的空白的应用程序，有没有2.0。*在该​​网页文件夹中运行的应用程序。还有该站点配置为ASP.NET 4.0，这是正确注册任何虚拟文件夹指向另一个目录等。

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.

的问题是，所述eurl.axd被拧在我的MVC路由参数。

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

在ASP.NET 4.0中的重大更改一文中的选项真的不适合我，因为没有任何2.0的组件在此应用程序，而我需要使用无扩展名的URL。

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.

更新我刚刚注意到，System.Web.MVC在GAC是2.0.0.0版本。如果这已更新至4.0 VS2010安装和4.0框架？

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?

我不明白为什么我看到这个错误了默认的ASP.NET MVC 2应用程序。帮助！

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

更新2/2011 - 已解决

说完终于尝试通过注册表黑客禁用无扩展名的URL，问题就消失了。我觉得反直觉，禁用无扩展名的URL，使无扩展名的URL的工作（在IIS6的通配符映射），但我会采取什么我可以得到的。

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.

更新二千〇十四分之十二

（梅利|快乐|和平）（圣诞节|光明|宽扎节| 12月）。

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

我忘了提，其他所有的Windows更新核爆注册表更改。这表现为奇怪的问题，其中一个请求到的http：//site.dom/bob 会失败，而 HTTP：//site.dom/bob / 会成功。玩的开心！ （请注意尾部的斜杠。）

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

推荐答案

这是微软的做法，使无扩展名的URL部分是由ASP.NET V4在IIS 6中。这里所描述的的 ASPNET V4重大更改文件。 （该文件为eurl.axd在搜索）。发生这种情况只与ASPNET V4。

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.

什么情况是：

1. aspnet_filter.dll ，实现ASPNET全局ISAPI筛选器（右键单击网站文件夹>属性才能看到它）检查每个进入的网址。对于那些没有扩展名的URL，然后ASPNET的轧液网址插入 /eurl.axd/some-long-number 进去。实际上，隆多是一个GUID没有破折号。

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.

您URL重写，站点特定ISAPI筛选器，运行旁边，看到的错位URL。因为你的规则，不要指望网址与奇序列注入到他们，你重写过滤器无法处理得当，而用户可能最终以404。

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.

这会发生在任何重写过滤器 - 赫利的ISAPI_Rewrite，IIRF，等等 - 当与IIS6和ASPNET v4的安装。它也可能发生在其他ISAPI筛选器 - 那些没有明确rewriters

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.

微软的意的情况发生：

1. aspnet_filter.dll ISAPI的过滤器的补充/eurl.axd/some-long-number到一个扩展名的URL。 （如果URL中有一个扩展，它留下孤军奋战，节电性能命中撞击管理code）。这是刚拿到个.axd中就有这么IIS6，在其默认的配置，将映射到 aspnet_isapi.dll的 ISAPI的扩展的（应用）。

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

在 aspnet_isapi.dll的 ISAPI的应用程序的回升要求，通过去除unmangles URL中的 / eurl.axd /有些长数，并把它传递给ASP.NET code旨在处理extensionlesses网址。这code处理该请求并没有意识到，/eurl.axd/some-long-number诡计没发生过。

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.

微软没有考虑到会发生什么步骤1和2的ASP.NET 4版本说明之间坐的一份说明有关.NET 2.0应用程序导致此错误的URL，检查ISAPI筛选器;这就是它可以发生只是一种方法。

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.

您有一些选择：

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

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

执行URL ASP.NET管道内重写。 （很明显，你可以只的rewrite管理在这种情况下的要求。）

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

在全球范围内的优先级要高于 aspnet_filter.dll 较高的安装您的ISAPI筛选器的URL重写。听起来像一个痛苦的我。

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

配置网站使用ASPNET V2，而不是ASPNET V4。

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

插入你的重写规则完全忽略与eurl.axd在他们的网址。这可能是简单的
 重写规则EURL \个.axd -

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.

祝你好运！

更新2011-08-10：看来，Windows更新该服务的.NET框架重新设置注册表项，它必须重新应用

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

修改2012-02-17 我们有这个问题，我们的团队花了几个小时的工作的问题之前，有人发现了这个埋在评论完成了我们的解决方案。 请注意，WOW64（即，在64位操作系统上运行32位工作进程），此注册表项必须设置为HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ASP.NET\4.0.30319.0\EnableExte‌​nsionlessUrls."

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

这篇关于ASP.NET MVC eurl.axd错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！