可能已经没有人会使用上一篇文章中的方法进行URL Rewrite了,因为提供URL Rewrite的组件早已铺天盖地了。
ASP.NET级别的URL Rewrite组件的原理很简单,其实只是监听BeginRequest事件,并且根据配置来决定目标URL。在我之前接触过的项目中,发现使用URLRewriter作为URL Rewrite组件的频率非常高,我想可能是因为那是微软提供的东西吧。
如果要使用URLRewriter,首先自然就是在web.config中配置一个HttpModule: 然后就是进行配置了(注:强烈建议使用configPath属性将配置提取成额外的文件,便于管理):
~/tag/([\w]+)/
~/Tags.aspx?Tag=$1
正则表达式是一个非常了不得的东西,能匹配,能捕获。在上面的例子中,我们把符合LookFor条件的"/tag/xxx"重新定位到Tags.aspx页面上,并且将xxx作为Tag这个QueryString项的值,这样就能够在代码中通过HttpContext.Request.QueryString["Tag"]来获得该值了。
URLRewriter的功能对于大多数应用来说已经足够了,但是我总是不喜欢。但如果非要问我不喜欢的原因,我也难说出个子丑寅卯来。可能仅仅是这个配置方式的问题吧。在使用URL Rewriter时,配置段往往会非常长,每个配置项需要从到共4行代码,一个规模不大的项目都很容易出现上百行的配置。"这也太XML了",我想,为什么不用XML Attribute呢?这样每个配置项就能缩短为1行了--不过,这是题外话。
所以如果我目前要做URL Rewrite,往往用的是Intelligencia出品的开源组件UrlRewriter.NET。虽然这个名字和前一个非常相似,但是功能却远超前者。该组件在使用上和URLRewriter比较接近(其实似乎所有的URL Rewrite组件都差不多),我们要做的也只是配置:
。与URLRewriter不同的是,UrlRewriter.NET使用了我喜欢的每规则一个节点的方式,这让整个项目的重写规则简洁不少。不过processing="stop"又是什么意思?这就要谈到UrlRewriter.NET在处理重写规则时的方法了。UrlRewriter.NET在找到一个匹配的重写规则时,不会就此停止,而会继续寻找其余的匹配项,最终生效的则是能够匹配当前请求的最后一个重写规则。如果我们需要UrlRewriter.NET在找到某个匹配项之后即生效,就需要将processing属性设为stop。例如在上面的配置里,如果"/User/"后紧跟着数字,则会使用用户ID进行查找,否则则认为当前所提供的是用户名。
如果UrlRewriter.NET仅仅是因为配置上显得比较简洁,它与URLRewriter相比实在没有什么优势。但是UrlRewriter.NET的能力远不止此,我们刚才使用的其实只是它提供的Action之一,初次之外它还提供了许多Action: 光有Action还不够,UrlRewriter.NET还提供了Condition、Transform、Default Document、 Parser、Error Handler、Logger等功能,并且能够通过Expression来"表示"复杂的逻辑。这哪还是配置,简直就是编程了!没错,用UrlRewriter.NET完全就可以通过配置来将一些请求--回复的逻辑表示出来,这无疑为我们带来了很大的方便。在这里我不可能详细说明UrlRewriter.NET的方方面面,感兴趣的朋友可以从它官方网站所提供的Reference来一窥究竟。
"得组件如此,夫复何求",不过我在这里还是要推荐另外一个组件。因为在某些特殊情况下,UrlRewriter.NET还不能满足我们的要求。嗯?不是能自行扩展吗?没错,可是--先卖个关子,本系列的最后一篇中来说明这个问题。UrlRewriter.NET提供了ASP.NET层面上的URL Rewriter。如果要在IIS层面上进行URL Rewrite,那么还必须使用其他方式。ISAPI Rewrite是IIS层面上进行URL Rewrite的著名组件,很可惜这是个商业组件,需要我们使用美刀来购买。因此我在这里推荐另一个开源产品:IIRF(Ionic's Isapi Rewrite Filter)。
由于是在IIS层面进行URL Rewrite,IIRF的配置方式和UrlRewriter.NET是不同的。如果要使用IIRF,则需要将IsapiRewrite4.dll添加到Web Site的ISAPI Filter列表中:
IIRF是通过ini文件来配置的,IsapiRewrite4.ini与IsapiRewrite4.dll放在同样的目录中即可: IIRF的重写规则是"RewriteRule []",每个部分之间的空格数目没有限制,不过一定要是空格,而不能是Tab等其他空白字符。"url-pattern"和"destination"自不必多说,关键在于modifier。IIRF的modifier有不少,在这里我先只介绍上面用到的两个。"I"表示匹配时大小写无关,"L"的作用和UrlRewriter.NET里的processing="stop"类似,IIRF在找到该匹配项时立即生效,而不会继续查找下去。
IIRF虽然是一个开源的组件,但是功能依然比较强大。尤其是结合了RewriteCond(Rewrite Condition)之后,可以实现比较复杂的重写规则。例如以下的配置则把UserAgent里包含Googlebot字样的根目录请求重写到某个特定的资源上:
ASP.NET级别的URL Rewrite组件的原理很简单,其实只是监听BeginRequest事件,并且根据配置来决定目标URL。在我之前接触过的项目中,发现使用URLRewriter作为URL Rewrite组件的频率非常高,我想可能是因为那是微软提供的东西吧。
如果要使用URLRewriter,首先自然就是在web.config中配置一个HttpModule: 然后就是进行配置了(注:强烈建议使用configPath属性将配置提取成额外的文件,便于管理):
~/tag/([\w]+)/
~/Tags.aspx?Tag=$1
正则表达式是一个非常了不得的东西,能匹配,能捕获。在上面的例子中,我们把符合LookFor条件的"/tag/xxx"重新定位到Tags.aspx页面上,并且将xxx作为Tag这个QueryString项的值,这样就能够在代码中通过HttpContext.Request.QueryString["Tag"]来获得该值了。
URLRewriter的功能对于大多数应用来说已经足够了,但是我总是不喜欢。但如果非要问我不喜欢的原因,我也难说出个子丑寅卯来。可能仅仅是这个配置方式的问题吧。在使用URL Rewriter时,配置段往往会非常长,每个配置项需要从到共4行代码,一个规模不大的项目都很容易出现上百行的配置。"这也太XML了",我想,为什么不用XML Attribute呢?这样每个配置项就能缩短为1行了--不过,这是题外话。
所以如果我目前要做URL Rewrite,往往用的是Intelligencia出品的开源组件UrlRewriter.NET。虽然这个名字和前一个非常相似,但是功能却远超前者。该组件在使用上和URLRewriter比较接近(其实似乎所有的URL Rewrite组件都差不多),我们要做的也只是配置:
。与URLRewriter不同的是,UrlRewriter.NET使用了我喜欢的每规则一个节点的方式,这让整个项目的重写规则简洁不少。不过processing="stop"又是什么意思?这就要谈到UrlRewriter.NET在处理重写规则时的方法了。UrlRewriter.NET在找到一个匹配的重写规则时,不会就此停止,而会继续寻找其余的匹配项,最终生效的则是能够匹配当前请求的最后一个重写规则。如果我们需要UrlRewriter.NET在找到某个匹配项之后即生效,就需要将processing属性设为stop。例如在上面的配置里,如果"/User/"后紧跟着数字,则会使用用户ID进行查找,否则则认为当前所提供的是用户名。
如果UrlRewriter.NET仅仅是因为配置上显得比较简洁,它与URLRewriter相比实在没有什么优势。但是UrlRewriter.NET的能力远不止此,我们刚才使用的其实只是它提供的Action之一,初次之外它还提供了许多Action: 光有Action还不够,UrlRewriter.NET还提供了Condition、Transform、Default Document、 Parser、Error Handler、Logger等功能,并且能够通过Expression来"表示"复杂的逻辑。这哪还是配置,简直就是编程了!没错,用UrlRewriter.NET完全就可以通过配置来将一些请求--回复的逻辑表示出来,这无疑为我们带来了很大的方便。在这里我不可能详细说明UrlRewriter.NET的方方面面,感兴趣的朋友可以从它官方网站所提供的Reference来一窥究竟。
"得组件如此,夫复何求",不过我在这里还是要推荐另外一个组件。因为在某些特殊情况下,UrlRewriter.NET还不能满足我们的要求。嗯?不是能自行扩展吗?没错,可是--先卖个关子,本系列的最后一篇中来说明这个问题。UrlRewriter.NET提供了ASP.NET层面上的URL Rewriter。如果要在IIS层面上进行URL Rewrite,那么还必须使用其他方式。ISAPI Rewrite是IIS层面上进行URL Rewrite的著名组件,很可惜这是个商业组件,需要我们使用美刀来购买。因此我在这里推荐另一个开源产品:IIRF(Ionic's Isapi Rewrite Filter)。
由于是在IIS层面进行URL Rewrite,IIRF的配置方式和UrlRewriter.NET是不同的。如果要使用IIRF,则需要将IsapiRewrite4.dll添加到Web Site的ISAPI Filter列表中:
IIRF是通过ini文件来配置的,IsapiRewrite4.ini与IsapiRewrite4.dll放在同样的目录中即可: IIRF的重写规则是"RewriteRule []",每个部分之间的空格数目没有限制,不过一定要是空格,而不能是Tab等其他空白字符。"url-pattern"和"destination"自不必多说,关键在于modifier。IIRF的modifier有不少,在这里我先只介绍上面用到的两个。"I"表示匹配时大小写无关,"L"的作用和UrlRewriter.NET里的processing="stop"类似,IIRF在找到该匹配项时立即生效,而不会继续查找下去。
IIRF虽然是一个开源的组件,但是功能依然比较强大。尤其是结合了RewriteCond(Rewrite Condition)之后,可以实现比较复杂的重写规则。例如以下的配置则把UserAgent里包含Googlebot字样的根目录请求重写到某个特定的资源上: