解析ASP.NET2.0下的URL重写
本文将通过实例比较ASP.NET下的三种典型URL重写方案——ISAPI重写（使用开源组件IIRF），ASP.NET2.0内置的urlMappings和基于自定义HTTPModule的URL重写（使用NBear.Web中的UrlRewriteModule实现），并探讨URL重写中可能遇到的陷阱及处理办法。
下载示例程序源码
需要手动为UrlRewriteSample目录添加一个到http://localhost/UrlRewriteSample的同名虚拟目录，允许匿名访问，并设置目录默认页为default.aspx。
另外，为了启用IIRF的URL重写支持，需要将UrlRewriteSample/bin目录下的IsapiRewrite4.dll添加为IIS默认网站的ISAPI过滤器。
设置重写规则
注意，我们的演示程序中将混合使用三种方式的URL重写，因此，需要为三种实现分别设置一些URL重写规则：
1、IIRF，对于IIRF，对应于IsapiRewrite4.dll，在相同的目录会有一个IsapiRewrite4.ini文件，除了默认的一些设置，我们在文件末尾添加了几条自定义规则如下：
# Custom RewriteRules
RewriteRule ^/UrlRewriteSample/test(.*).aspx /UrlRewriteSample/Default.aspx?page=$1
RewriteRule ^/UrlRewriteSample/folder/(.*).aspx /UrlRewriteSample/Default.aspx?folder=$1
RewriteRule ^/UrlRewriteSample/folder/? /UrlRewriteSample/Default.aspx?folder=default
熟悉正则表达式的朋友应该很容易理解上面这三条规则。
规则一将形如testXXX.aspx这样的页面访问，重写为Default.aspx?page=XXX这样的页面；
规则二将形如folder/XXX.aspx的路径，重写为Default.aspx?folder=XXX这样的页面；
规则三将不带任何文件的folder目录的访问，重写为Default.aspx?folder=default这样的页面。
2、urlMappings是ASP.NET2.0内置支持的URL重写配置块，它应该包含在web.config的<system.web>配置块中。但是，这个内置的URL重写支持不支持正则表达式，因而只能用来实现一对一的路径和页面的重写。urlMappings的配置内容包含在下面的Web.config文件中。
3、NBear.Web.Modules.UrlRewriteModule则是NBear中实现的一个基于HTTPModule的URL重写实现，它允许使用正则表达式来描述重写规则。
注意，代码中包含了urlMappings配置和用于NBear.Web.Modules.UrlRewriteModule重写规则。为了比较着几种重写方案，正则表达式基本上是和前面的IIRF定义中的规则类似的。
页面测试
定义完这些重写规则，我们就可以试着在页面中使用它们了。例如，如果我们写一个测试页面如下：
Default.aspx
Default.aspx.cs
注意，Default.aspx页面会输出当前呈现的实际页面及其QueryString参数。
运行该页面，分别点击页面中的链接，我们会看到，貌似所有的URL重写一切正常。但是，当试着点击页面中的按钮，我们马上会发现，页面postback后，浏览器地址栏中的链接变成了那个被重写后的地址，而不是，原来显示于地址栏的虚拟地址了。这是一个严重的不一致，没道理我点击页面的按钮，在没有跳转到其他页面的情况下，地址栏显示另一个页面地址，不是吗？
要解决这个问题，我们只需要为form添加一个onsubmit事件处理如下：
<form id="form1" runat="server" onsubmit="this.action=document.location.href">
添加该事件处理，就能在页面postback提交之前，重置页面的地址。
为前面的页面添加onsubmit之后，我们发现，postback不再会改变地址栏地址显示了。太棒了~~
。。。
先别沾沾自喜太多，你确认试过点击最后一组链接中的buildin default page和section default page了吗？
你会发现，这两个链接根本不能显示。为什么呢？为什么类似的folder default page可以正常显示，而另两个不能显示呢？
回到前面的规则定义部分，我们就能发现，folder default page使用的是由IIRF这个ISAPI定义的规则，而另两个则使用的是内置于ASP.NET2.0的HTTPModule的重写规则（本质上，urlMappings也是使用HTTPModule来实现重写的，所以，除了不支持正则表达式之外，它也包含自定义HTTPModule方式实现的所有缺点）。
在IIS的ISAPI层面，是可以截获所有的页面请求的，哪怕指定的页面、目录根本不存在。但是，ASP.NET解析器则只有在对页面的请求被IIS转发过来时，才能处理。我们知道，IIS可以忽略对链接的虚拟目录是否存在的检测，但是，却无法检测非ASP.NET支持的文件扩展名的链接（我们固然可以在IIS中将所有类型的扩展名都映射到ASP.NET解析器，但是，如果我们有设置IIS的权限，为什么还要用性能更低，限制更多的ASP.NET方式的URL重写，而不使用基于ISAPI方式的重写呢？）。所以，为了让这两个不能显示的页面能正常显示，一方面，我们要在IIS中设置默认页，如default.aspx，另一方面，需要让IIS对某个不带aspx扩展名的链接，如这里只包含某个目录的名称的链接转发到默认页。
要做到这一点，我们需要在我们的应用程序中，为buildin和section分别将两个对应的目录，并且，在目录中创建两个空的default.aspx页面。尽管这样的default.aspx页面实际上永远不会被真正执行，但是有他们的帮助，就能让IIS顺利地将页面请求转发至ASP.NET解析器，从而，使得基于HTTPModule的URL重写规则，被执行。
好了，创建这两个目录及default.aspx文件，我们就能修复该问题了。
。。。
别急着庆祝，还是多做点测试为好。：）
我们来对页面上的链接反复点击点击，folder page -> section page -> folder page -> section page...等等，打住，看到浏览器地址栏发生了什么吗？这不是恐怖活动，但是。。。也差不多了。我们看到我们可爱的地址，变成了...folder/section/folder/section...aspx。
想想是为什么呢？看看我们的aspx文件。。。我想你一定想到了。对了，都是相对路径惹的祸！
我们可爱的的相对路径一顶是同学们最常使用的，但是，浏览器在处理相对路径时，是以浏览器上接受的url地址为基础进行计算的，也就是说，如果当前的地址为folder/1.aspx，那么，很显然，./section/2.aspx这个页面，对应的自然是folder/section/2.aspx了，问题就出在这儿了！没有URL重写时，不会有这样的情况出现。但是URL重写，并且，将一个带假目录的虚拟地址重写到一个不带假目录的页面时，由于浏览器客户端和服务端此时的当前页面计算方法是不同的，就会发生相对路径的匹配错误问题！真实很严重的问题啊！
解决的办法，只有使用绝对路径！但是，我们当然不会傻到对每个链接直接使用绝对路径的，呵呵：）
将Default.aspx中的所有相对路径都使用Page.ResolveUrl进行包装如下，在输出页面时就将地址转换为绝对路径，就能解决这个恐怖的相对路径陷阱了。当然，也别忘了加上onsubmit事件处理代码：
Default.aspx
好了，再试一试点击页面上的链接和按钮，多点几次，再点，再点。。。
。。。
呼~
终于搞定了吧！^-^