在之前的文章里我们已经谈论了有关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组件来说，想要实现这个并不容易。商业化的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。例如我们现在要实现将“http://jeffz.domain.com/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里写，在项目中还是建议使用额外的HttpModule来实现）。
protected void Application_BeginRequest(object sender, EventArgs e)
{
HttpContext context = HttpContext.Current;
string host = context.Request.Url.Host;
string owner = host.Substring(0, host.IndexOf('.'));
context.RewritePath(context.Request.RawUrl + "?owner=" + owner);
}
经过两次URL Rewrite，已经实现了我们想要的效果（在实际项目中，上面的代码不能直接使用，因为需要判断是否有Query String等等）。
此外，ASP.NET级别的URL Rewrite只能在ASP.NET里工作（显然的事情），如果要让URL Rewrite支持PHP，RoR等其他服务器技术，就只能使用IIS级别的URL Rewrite了（或者其他服务器技术提供的URL Rewrite功能）。
有些特殊字符是不允许出现在URL中的，或者一旦出现在URL里以后，请求的含义就被改变了。例如我们需要对搜索页面进行URL Rewrite，将“/Search/xxx”重写为“/Search.aspx?xxx”，然后可以根据问号后面的字符串获得用户提供的关键字。如果使用UrlRewriter.NET，我们就会使用如下的配置：
<rewriter>
<rewrite url="^/Search/(.+)$" to="~/Search.aspx?$1" processing="stop" />
</rewriter>
普通情况下，这个URL Rewrite工作正常。但是如果用户使用“%” 作为关键字，情况就不一样了，因为我们会收到如下的错误页面提示：
这是因为URL中是不允许出现“%”的。大家可以去各种网站上尝试着请求一些例如“ABC%25DEF”的路径（“%25”之后即为“%”），大都能发现“400 Bad Request”错误。不过将“%”放在Query String里倒是合法的——对阿，我们不是将keyword重写到Query String里了吗？为什么还是不行呢？这还是由于ASP.NET执行方式决定的。
Bad Request是在上图的步骤3，也就是还在进行初始化的时候就被确定了。而我们的URL Rewrite是在第4步BeginRequest事件中才发生的。当请求中带有非法字符时，我们根本还没有机会进行URL Rewrite。
那么我们怎么处理这个问题呢？在一般情况下，我们在客户端将%去除也不会有太大问题（有些站点的确是这么做的），但是如果非要保留呢？那么就使用Query String来传递参数吧，或者我们也可以使用IIS级别的URL Rewrite。还是以IIRF为例：
RewriteRule ^/Search/(.+)$ /Search.aspx?$1 [I, L, U]
当请求被发送到IIS之后（步骤一），并且在选择应该交给哪个ISAPI执行（步骤二）之前就发生了URL Rewrite。经过了URL Rewrite之后的地址，其中的“%”已经被转移到了Query String中，这时候交由ASP.NET处理时自然已经合法了。
最后我们来讨论出错页面的配置。例如，一般来说我们都会为应用配置一个404错误页面，这样用户在访问一个不存在的资源时我们可以给他查看一个特定的页面，而不是默认的错误提示。但是在这一点上，不同级别的URL Rewrite就要使用不同的方法进行配置。
如果我们使用了ASP.NET级别的URL Rewrite，一般来说我们已经在IIS里设置了Wildcard Mapping，这样任意的请求（包括html，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方式的关键，按照程序运行的方式来思考，相信一般情况下不太会遇到难以处理的问题。