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

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方式的关键，按照程序运行的方式来思考，相信一般情况下不太会遇到难以处理的问题。