重提URL Rewrite（4）：不同级别URL Rewrite的一些细节与特点（转老赵blog）

在之前的文章里我们已经谈论了有关URL Rewrite的几个主要的方面。在本系列的最后一篇文章中，我们就来讨论一下有关不同级别URL Rewrite的一些细节与特点。

理论上说，IIS级别的URL Rewrite使用C或C++编写，比使用托管代码编写的ASP.NET级别URL Rewrite性能要高。但是我认为这方面的差距在大部分情况下可以忽略不计，这种性能几乎不可能成为性能瓶颈。因此选择何种级别的URL Rewrite一般不会由您应用程序的性能要求来决定。那么到底应该使用哪种级别的URL Rewrite呢？在使用不同级别的URL Rewrite之后，我们又该注意点什么呢？我在这里谈谈我个人的看法。

对URL Rewrite功能上的要求

虽说目前的URL Rewrite组件在功能上已经能够满足大部分的应用，但是在某些时候，我们的确还是会需要一些特殊的功能。例如根据域名进行URL Rewrite，就目前的URL Rewrite组件来说，想要实现这个并不容易。商业化的ISAPI Rewrite目前已经可以支持这一点，可惜开源的UrlRewriter.NET和IIRF在这方面功能都有所不足。它们都是根据请求相对于该站点的路径来匹配，至于请求的是哪个域名并不能作为匹配条件来使用。这就要求我们对URL Rewrite组件进行扩展。对于大部分.NET开发人员来说，托管代码自然是开发首选，这时可能就要选择ASP.NET级别的URL Rewrite重写组件了。不过目前网上能找到不少扩展的例子，无论是ASP.NET级别的UrlRewriter.NET还是IIS级别的IIRF。

不过事实上，如果要实现上述功能，我们也可以分两步进行。首先我们在IIS级别使用IIRF进行URL Rewrite，接着在ASP.NET级别作进一步的URL Rewrite。例如我们现在要实现将“/articles”重写为“/ArticleList.aspx?owner=jeffz”，就可以先在让IIRF做第一次URL Rewrite，目的是将“/articles”重写至“/ArticleList.aspx”。

RewriteRule    ^/Articles$    /ArticleList.aspx      [I, L, U] 

这样，ASP.NET引擎就会直接接收到一个针对/ArticleList.aspx的请求了。然后在ASP.NET内部，我们可以作第二次的URL Rewrite（方便起见，我这里还是在Global.asax里写，在项目中还是建议使用额外的，jpg等）都会交由ASP.NET处理。如果请求了一个不存在的资源，404错误将由ASP.NET发出，因此404错误页面应该在web.config中进行配置：

<customErrors mode="On" defaultRedirect="GenericErrorPage.htm">
  <error statusCode="404" redirect="FileNotFound.htm" />
</customErrors>

如果我们使用了IIS级别的Url Rewrite，我们不会配置Wildcard Mapping。也就是说我们只有在Rewrite之后的地址为aspx（或其他原本就该交由ASP.NET ISAPI处理）的情况下，ASP.NET引擎才会开始工作。如果用户请求了一个不存在的资源，那么404错误将由IIS发出，这时候404错误页面应该在IIS里进行配置：

至此，有关URL Rewrite的话题已经讨论完了。在实际开发中肯定还会遇到各种各样不同的情况，但是只要理解了URL Rewrite方式的关键，按照程序运行的方式来思考，相信一般情况下不太会遇到难以处理的问题。