|
 
|
[软件故障] ISAPI_Rewrite运行在.NET Framework 4.0+IIS 6.0环境下404错误解决方案
今天以前的同事让我帮他上服务器看看，他把页面伪静态之后，出现404错误，为什么会出现这样的问题呢，仔细研究才发现，原因如下：
因为ASP.NET4.0在安装的过程中，已经在IIS6做了一些手脚，让它可以原生的支持的无后缀的URL请求，那么它究竟是做了什么事情呢？在实现这个功能的作者Thomas Marquardt的这篇博客上的一段话解释了它的工作原理，大概是这样的：
ASP.NET 4.0在安装的时候，会在IIS6注册一个ISAPI Filter，叫做”aspnet_filter.dll”，ISAPI Filter会先于ISAPI处理程序前执行，它会在所有的的无后缀的URL后面加一串字符“/eurl.axd/GUID”， 同时ASP.NET 4.0还会在IIS默认添加一个请求映射规则“*.axd”，映射到aspnet_isapi.dll。此时，所有的无后缀URL加上“/eurl.axd/GUID”后都会变成带.axd后缀，这样就匹配*.axd的映射规则进行ASP.NET的处理通道。在进入ASP.NET通道后，ASP.NET处理程序会删除掉“/eurl.axd/GUID”，让它还原到无后缀的原始情况，并且不会对后续的请求处理带来任何影响。此时，所有的无后缀请求，就进入了ASP.NET的处理通道中，在默认情况下，ASP.NET4.0的全局的web.config中配置了DefaultHttpHandler来接收无后缀的URL请求，但是我们也可以随意更换默认处理程序（比如ASP.NET MVC处理程序）来处理无后缀的URL请求。
从上面的解释中， 我们不难看到，这与IIS7的集成模式有本质的不同，它并不是很原生的处理方案。不得不说，这并不是一个非常流畅的解决方案，也许这也是不得以之下的非常之举。但是其实在没有ASP.NET MVC以前，对无后缀的URL请求的支持并不是那么迫切需要。即使有需要，也是通过一个URL Rewriter组件，而因为首先要进入ASP.NET 处理通道，所以这种URL Rewriter组件也需要ISAPI级别的扩展。当我们在ASP.NET 4.0的程序中，需要用类似的组件的时候，可能就会需跟上面的功能有所冲突，此时，我们可能就会需要禁用ASP.NET4.0对无后缀URL请求的这个功能。这时候你可能修改注册表相关键值（并重启IIS），或者是删除aspnet_filter.dll的注册（因为在这步增加了/eurl.axd/GUID）。
解决方法：
打开注册表找到“HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\ASP.NET\\4.0.30319.0”，添加键值名为“EnableExtensionlessUrls” 类型为“DWORD”的键值，并设置值为“0”。然后在cmd中运行“IISRESET”，重启IIS以读取注册表修改后的内容。注：此项修改就是关闭 ASP.NET 4.0对无扩展URL的处理，若将此项键值设为“1”则开启。 |
|
鲁公网安备 37120302000001号
