阿不

潜水

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
  212 随笔 :: 0 文章 :: 3066 评论 :: 75 引用

公告

看到haack的这篇文章《ASP.NET MVC 3 Extensionless URLs on IIS 6》,我才知道在IIS6的环境下运行ASP.NET4.0程序,我们已经可以原生的支持没有后续名(扩展名)的URL请求,而不需要再做通配符映射,这对我们在IIS6部署ASP.NET MVC站点来说,相当的重要。

在以前,我们要让ASP.NET MVC程序可以正常工作在IIS6上面,要么在我们的程序路由中添加*.mvc(或其它任意后缀),并且在部署时添加isapi映射规则,把*.mvc映射到aspnet_isapi.dll,让他交由ASP.NET处理程序进行处理,但一般情况下,这种做法我们都不会采用,用户体验不好,至少到目前为止,我还没有见过类似.mvc的网站;要么,我们可以在部署时,添加通配符映射(wildcard mappings),映射到aspnet_isapi.dll,它的作用就是把所有的URL请求都交由ASP.NET程序处理,但是这样做的使得很多原本不需要经过ASP.NET处理的请求,比如,样式,脚本,图片等静态资源都需要经过ASP.NET通道处理一遍,后果是可能会带来一定的性能影响。虽不完美,但大多数人还是会选择这种方案。

现在如果我们的ASP.NET站点基于ASP.NET 4.0,我们就不需要再做类似的事情了,因为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)。

haack文章最后还提到,他想要去确认这种行为的时候,出现了一点小问题,而它只是做了几步就可以很简单的修复这些问题。可能是在安装ASP.NET 4.0的时候,某些IIS注册行为没有被正确执行才导致的这些错误的发生。但我自己目前还没有IIS6的环境来验证,但我相信,这个功能对于我们希望在IIS6部署ASP.NET MVC站点来说是非常有意义的。

posted on 2010-12-25 23:36 阿不 阅读(...) 评论(...) 编辑 收藏