在ASP.NET中实现Url Rewriting002[]

使用HttpHandler来调用网址重写

　　除了上面所述方法外，网址重写也可以放入HttpHandler或者HttpHandlerFactory中调用。HttpHandler是一个负责针对特定请求生成相应内容的类，而HttpHandlerFactory返回一个HTTP的实例，该实例针对特定请求生成相应内容。

　　本节将着眼于为这些ASP.NET页面创建一个网址重写的HttpHandlerFactory。创建HttpHandlerFactory必须实现IHTTPHandlerFactory接口，它包括一个GetHandler()方法。ASP.NET引擎在初始化这些HttpModule后做出决定针对该请求调用相应的HttpHandler或者HttpHandlerFactory，在调用HttpHandlerFactory的时候，针对该Web请求以及随同的其他信息的HttpContext中经过的的HttpHandlerFactory的GetHandler()方法将被ASP.NET引擎调用，HttpHandlerFactory必须返回一个能委托该请求的对象，并且该对象要能实现IHttpHandler接口。

　　要通过一个HttpHandler来调用网址重写，可以先创建一个HttpHandlerFactory，它的GetHandler()方法检查所请求的网址并决定是否需要调用网址重写。如果要调用网址重写的话则调用前文所述的已通过检查的HttpContext对象的RewritePath()方法。最后该HttpHandlerFactory返回一个由类System.Web.UI.PageParser的GetCompiledInstance()方法返回的HttpHandler。（这与内嵌于ASP.NET页面的HttpHandlerFactory（PageHandlerFactory）的工作原理相同。）

　　在所有HttpModule被初始化后，HttpHandlerFactory就开始被实例化。把网址重写放在这些事件场所的最后一个里头调用的时候，也会碰到相同的问题：文件授权将会失效。如果非要依赖于Windows验证和文件验证的时候，你可能得使用HttpModule来调用网址重写了。
下一章我们着眼于如何构建一个可重用的网址重写引擎，使用下文所提的这些示例均以真实案例作为参照，在作者主页上提供下载。先用用一个简单的网址重写的例子来探讨如何实现网址重写，紧接着将利用网址重写引擎中正则表达式的强大处理能力来展示真正“隐蔽”的网址重写技术！

　　使用网址重写引擎实现简单的网址重写

　　为了便于在Web应用程序中实现网址重写，我构建了一个网址重写引擎，该引擎提供下列功能：

　　·可以在web.config文件中为页面开发者定义其所使用的网址重写引擎的规则；

　　·通过使用正则表达式来使所制定的网址重写规则具有更加强大的重写能力；

　　·能够通过简单配置即可在HttpModule和HttpHandler中使用网址重写。

　　本节只探讨通过HttpModule来实现网址重写，要了解如何通过HttpHandler来实现网址重写请下载本文提供的代码。

　　1. 设置网址重写引擎的配置信息

　　我们来探讨一下在web.config中网址重写规则的配置节。首先必须在web.config文件中指出是否需要在HttpHandler或者HttpModule中调用网址重写，在web.config中，下文已经包含了两个已经被注释掉的配置节：

＜!--
＜HttpModules＞
＜add type="URLRewriter.ModuleRewriter,URLRewriter" name="ModuleRewriter"/＞
＜/HttpModules＞
--＞

＜!--
＜httpHandlers＞
＜add verb="*" path="*.aspx" type="URLRewriter.RewriterFactoryHandler,URLRewriter" /＞
＜/httpHandlers＞
--＞

　　被注释掉的＜HttpModules＞为配置使用HttpModule调用网址重写；注释掉的＜httpHandler＞为配置使用HttpHandler调用网址重写。
不论配置使用＜HttpModules＞还是＜httpHandlers＞调用网址重写，除此之外还须配置网址重写规则，一条重写规则包括两项字符串：请求URL中的查找模式和针对该模式的匹配成功后的替换字符串。该信息在web.config文件中用下列标签描述：

＜RewriterConfig＞
＜Rules＞
＜RewriterRule＞
＜LookFor＞pattern to look for＜/LookFor＞
＜SendTo＞String to replace pattern with ＜/SendTo＞
＜/RewriterRule＞
＜RewriterRule＞
＜LookFor＞pattern to look for＜/LookFor＞
＜SendTo＞String to replace pattern with ＜/SendTo＞
＜/RewriterRule＞

＜/Rules＞
＜/RewriterConfig＞

　　每一条规则都用一个＜RewriterRule＞元素表示，以＜LookFor＞节表示查询模式，当查询模式发现匹配字符串时便用＜SendTo＞节表示的字符串进行替换。这些规则从上到下进行查询匹配，如果找到一个匹配则按此规则执行网址重写，并且停止查找。

　　配置＜LookFor＞节要使用正则表达式来进行字符串匹配和替换。（在此我们举一个例子来说明如何使用正则表达式来对字符串进行匹配和替换。）既然该查找模式是一个正则表达式，那么要注意避开对正则表达式保留字符串的直接使用。（正则表达式的保留字符串包括有：.，?，^，$，等等，可以通过在前面加上一个反斜线来引用这些保留字符，例如\.表示引用一个句点）

　　2. 使用HttpModule来执行网址重写

　　创建一个HttpModule很简单，只要创建一个实现IHttpModule接口的类，该IHttpModule接口定义了两个方法：

　　·Init(HttpApplication)，该方法在HttpModule初始化时引发，通过该方法为HttpApplication事件调用相应的事件委托；

　　·Dispose()，当相应请求处理结束并发送回IIS调用此方法，通过此方法执行最终所有的清理和回收程序。

　　为了更加方便地为网址重写创建HttpModule，从一开始我就创建一个抽象的基类（BaseModuleRewriter），该类实现了IHttpModule接口。在Init(HttpApplication)事件中，它通过BaseModuleRewriter_AuthorizeRequest方法引发了HttpApplication的AuthorizeRequest事件，该BaseModuleRewriter_AuthorizeRequest方法通过该类的Rewrite()方法重写传入参数HttpApplication对象的内部请求虚拟路径（Path）。在BaseModuleRewriter对象中，该Rewrite()方法是抽象的，并且没有实际内容，但在继承自该类的对象中必须重载Rewrite()方法并为该方法提供实际内容。

　　通过对该基类的继承，所有需要做的工作就是创建一个继承自BaseModuleRewriter的类，重载Rewrite()方法并在该方法中添加网址重写逻辑代码。下文列出BaseModuleRewriter代码：

public abstract class BaseModuleRewriter : IHttpModule
{
public virtual void Init(HttpApplication app) {
// WARNING! This does not work with Windows authentication!
// If you are using Windows authentication,
// change to app.BeginRequest
app.AuthorizeRequest += new EventHandler(this.BaseModuleRewriter_AuthorizeRequest);
}

public virtual void Dispose() {}

protected virtual void BaseModuleRewriter_AuthorizeRequest(object sender, EventArgs e) {
HttpApplication app = (HttpApplication) sender;
Rewrite(app.Request.Path, app);
}

protected abstract void Rewrite(string requestedPath, HttpApplication app);
}

　　注意：该BaseModuleRewriter类将网址重写放在AuthorizeRequest事件中调用，如果要使用Windows验证并使用文件验证模式时请修改代码将网址授权放在BeginRequest或者AuthenticateRequest事件中。

　　ModuleRewriter继承自BaseModuleRewriter，并真正意义地实现了网址重写的操作，该类仅包含一个重载了的方法Rewrite()，其内容如下文所示：

protected override void Rewrite(string requestedPath, System.Web.HttpApplication app)
{
// get the configuration rules
RewriterRuleCollection rules = RewriterConfiguration.GetConfig().Rules;
// iterate through each rule
for(int i = 0; i ＜ rules.Count; i++)
{
// get the pattern to look for, and
// Resolve the Url (convert ~ into the appropriate directory)
string lookFor = "^" +
RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, rules[i].LookFor) + "$";
// Create a regex (note that IgnoreCase is set)
Regex re = new Regex(lookFor, RegexOptions.IgnoreCase);
// See if a match is found
if (re.IsMatch(requestedPath))
{
// match found - do any replacement needed
string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.Replace(requestedPath, rules[i].SendTo));
// Rewrite the URL
RewriterUtils.RewriteUrl(app.Context, sendToUrl);
break; // exit the for loop
}
}
}

　　该Rewriter()方法以获取web.config文件中的网址重写规则的设置为起始，它通过循环访问各条网址重写规则，每次均获取当前规则中的LookFor属性，用正则表达式验证并判断是否查找是否对当前请求的网址是否有匹配。

　　如果发现一条匹配，将用当前规则的SendTo值对请求的路径执行一个正则表达式替换，替换后的地址通过参数的形式传给RewriterUtils.RewriteUrl()方法，RewriterUtils是一个帮助类，它提供一对HttpModule和HttpHandler都可以使用的静态方法，RewriterUrl()方法只是简单地调用了HttpContext对象的RewritePath()方法。

　　注意：你已经注意到了当执行正则表达式匹配和替换的时候调用了一个RewriterUtils.ResolveUrl()方法。该帮助方法简单地替换了应用程序路径中“~”的所有实例。

　　我们已经探讨了主要的部分，但是还有其它一些组件诸如将web.config文件中XML格式化了的网址重写规则反序列化至一个对象的类定义、通过HttpHandlerFactory实现网址重写的类定义等。本文最后三节将通过一些真实案例来探讨网址重写的技术。

　　3. 用网址重写引擎实现简单的网址重写

　　为了更好地示范网址重写引擎的运行，我们来建立一个ASP.NET Web应用程序来实现简单的网址重写引擎。假定我们为一家在线销售各类商品的公司服务，这些产品划分为以下类别：

　　分类编号(CategoryID) 分类名称(CategoryName)
　　　1 　　　　　　　　　饮料（Beverages）
　　　2　　　　　　　　　 调味品（Condiments）
　　　3　　　　　　　　　 工艺品（Confections）
　　　4　　　　　　　　　　日记本（Diary Products）
　　　... ...
　　
　　假定已经建立好一个名为ListProductsByCategoryID.aspx的ASP.NET页面文件，它通过查询参数获取一个分类编号，并根据此编号获取所有该分类下的所有商品。如果用户想浏览所销售的饮料类商品可以通过ListProductsByCategoryID.aspx?CategoryID=1来访问，如果用户想浏览所销售的日记本类商品可以通过ListProductsByCategoryID.aspx?CategoryID=4来访问。假定还有一个页面ListCategories.aspx，它列出所有代售商品的分类编号。

　　显然这里发现了一个网址重写的案例。对于用户来说他们所输入的地址不具有任何实际意义并且不具备任何“隐蔽性”，倒不如使用网址重写引擎让用户去访问/Products/Baverage.aspx地址，系统将该地址重写到ListProductsByCategoryID.aspx?CategoryID=1。我们可以在web.config文件中来完成网址重写任务：

＜RewriterConfig＞
＜Rules＞
＜! —- Rules for products lister --＞
＜RewriterRule＞
＜LookFor＞~/Products/Baverage.aspx＜/LookFor＞
＜SendTo＞~/ListProductsByCategoryID.aspx?CategoryID=1＜/SendTo＞
＜/RewriterRule＞
＜/Rules＞
＜/RewriterConfig＞

　　很明显地看到，搜索用户访问的路径是否匹配/Products/Baverage.aspx，如果匹配的话，则将网址重写到/ListProductsByCategoryID.aspx?CategoryID=1。

　　注意：你会发现＜LookFor＞节点中避免直接在“Baverage.aspx”中使用句点“.”是因为＜LookFor＞节点的值是正则表达式的匹配模式，在正则表达式中句点符号是一个特殊字符，它表示匹配任何一个字符，也就是说如果访问BaverageQaspx时也会发生匹配，为了避免发生这个句点引起的匹配我们得在该句点符号前面加上一个“\”，表示引用句点符号。

　　通过该规则定义，当用户访问/Products/Baverage.aspx文件的时候，他们将看到代售的饮料类商品列表信息。图3为访问/Products/Baverage.aspx地址时的浏览器截图，注意在浏览器中地址栏上显示的是用户输入的/Products/Baverage.aspx地址，但是实际访问的地址却是网址重写后的/ListProductsByCategoryID.aspx?CategoryID=1。（事实上，在服务器上根本就不存在/Products/Baverage.aspx文件！）


图三．网址重写后的对商品分类的请求

　　和/Products/Baverage.aspx类似，下一步我们添加其它分类的重写规则，只需简单地在web.config文件中＜Rules＞中在添加其他＜RewriteRule＞节即可。该演示完整的重写规则集合请参考下载文档的web.config文件中的定义。

　　为了让该网址更具有“隐蔽性”，如果让用户把/Products/Baverage.aspx后面Baverage.aspx一段截去，在浏览器中输入/Products/来浏览产品分类列表会更好一些。乍一看，这项任务微不足道，只需添加一条网址重写规则将/Products/映射到/ListCategories.aspx即可。然而这里有一个微妙之处，你必须先创建一个/Products/目录，并在里面放一个空文件Default.aspx。

　　要认识为什么这些额外的步骤是必须的，先回顾一下前文。网址重写引擎是处于ASP.NET一级的，也就是说，如果ASP.NET没有获得处理请求的机会的话，网址重写引擎就不能对输入的网址请求作出判断。此外，IIS仅在请求文件包含相应扩展名时才将请求转交给ASP.NET引擎。如果用户访问/Products/，IIS并不知道其扩展名是什么，于是它检查该目录下的文件看是否包含有默认首页文件名（Default.aspx,Default.htm,Default.asp,等等，这些文件名在IIS管理工具对话框中Web服务器属性对话框中的文档标签中定义。）当然，如果/Products/目录不存在的话，IIS将返回一个HTTP 404错误。

　　所以我们需要创建一个/Products/目录并在该目录下额外创建一个空文件Default.aspx，IIS会检查该目录下的文件，发现有一个默认文件名Default.aspx，于是将请求转交给ASP.NET，这样，网址重写引擎才能生效。

＜RewriterRule＞
＜LookFor＞~/Products/Default.aspx＜/LookFor＞
＜SendTo＞~ListCategories.aspx＜/SendTo＞
＜/RewriterRule＞

　　通过该规则，用户访问/Products/Default.aspx或者访问/Products/都可以看到如图四所示的产品分类列表。


图四.在网址上添加“隐蔽性”

 

　4.处理回送数据

　　如果要重写的网址上包含有服务器端Web Form并执行数据回送，当该Web Form回送数据时会暴露出真实的网址，也就是说，当用户访问/Products/Baverage.aspx时，浏览器上地址栏显示的也是/Products/Baverage.aspx，但是实际上是访问/ListProdutsByCategoryID.aspx?CategoryID=1的内容，如果ListProductsByCategoryID.aspx页面执行了数据回送的话，用户被数据回送定向给原始的/ListProductByCategoryID.aspx?CategoryID=1页面上，而不是/Products/Baverage.aspx页面。这虽然不是什么大问题，但是用户会觉察到点击一个按钮时网址发生了的变化，这也许会令人不安，因为如果出于网址安全的角度来说，直接把真实的网址暴露出来了。
之所以发生这种现象的原因是当Web Form在呈现之时就明确地设置其action属性为当前Request对象中文件路径的值。当然，在Web Form呈现之时，从/Produts/Baverage.aspx到/ListProductsByCategoryID.aspx?CategoryID=1的网址重写就已经执行完毕了，这意味着Request对象所汇报的是当前用户所访问的地址是/ListProductsByCategoryID.aspx?CategoryID=1。这么看来，只需让该服务器端表单在呈现之时不呈现action属性即可解决问题了。（对浏览器来说，如果不设置action属性的话，那么在提交的时候将使用其默认值。）

　　然而不幸的是该Web Form不会允许你指定action属性，也不会允许你通过设置一些属性来达到禁用呈现action属性的目的。得自行继承System.Web.HtmlControls.HtmlForm这个类，并重载该类的RenderAttribute()方法，明确指出该类不呈现acton属性。

　　感谢继承这个强大的功能，使得我们很简单就获取了HtmlForm这个类下所有的功能定义，只需少量几行代码就达到所需目的，完整代码如下所示：

namespace ActionlessForm
{
public class Form:System.Web.UI.HtmlControls.HtmlForm
{
protected override void RenderAttributes(System.Web.UI.HtmlTextWriter writer)
{
writer.WriteAttribute("name",this.Name);
base.Attributes.Remove("name");

writer.WriteAttribute("method",this.Method);
base.Attributes.Remove("method");

this.Attributes.Render(writer);
base.Attributes.Remove("action");
if (base.ID!=null)
{
writer.WriteAttribute("id",this.ClientID);
}
}
}
}

　　对RenderAttributes()方法重载的代码包含了原类HtmlForm的RenderAttributes()方法全部的代码内容，只是简单地去掉了设置action属性这一节。

　　当创建并编译了这个类后，将其添加到引用目录即可在该ASP.NET Web应用程序中使用。为了将原有HtmlForm类替换，只需简单地在页面顶部添加下列代码：

＜% @ Register TagPrefix = " skm " Namespace = " ActionlessForm " Assembly = " ActionlessForm " %＞

　　然后将＜Form runat=”server”＞标签替换为

＜skm:Form id="Form1" method="post" runat="Server"＞

　　并将结束标记＜/Form＞替换为

＜skm:Form＞

　　你可以查看该文档相关下载中的ListProductsByCategoryID.aspx文件中的自定义Web Form，该下载已经提供了完整的Visual Studio.NET项目文件包。

　　注意：如果你打算进行网址重写的地址不执行数据回送，则没有必要使用该自定义Web Form的类。

　　创建真正“隐蔽”的网址

　　上一节简单网址重写的示例展示了如何通过新的网址重写规则来轻松地配置网址重写引擎，本节将通过出众的正则表达式来展示网址重写的强大威力。

　　时下正在流行Blog，很多人都拥有一个自己的Blog。不论你是否对Blog感到陌生，他们正在不断地更新自己的Blog页面，这些页面就像一个个人日记本一样。大多数Bloger只是简单地记录每天发生的事情，也有一些聚焦于某一主题，比如影评、球迷组织、电脑技术等。

　　Blog可以在任何地点由作者进行更新，更新次数可以是一天多次，也可以是一周一两次。在Blog页面上只显示最近10条更新，但事实上所有的Blog软件都提供了存档记录，访客可以阅读其历史记录。有了“隐蔽”的网址，Blog应用程序将变得更加强大。假定你通过/2004/02/14.aspx来查询自己的Blog上的文章，你会为阅读到2004年2月14日的Blog感到惊讶吗？此外你可能为了访问2004年2月所有的Blog而将该地址裁减为/2004/02/，要访问2004年所有的Blog，你可能会试着去访问/2004/。

　　在维护一个Blog的时候，如果将这种具有“隐蔽性”的网址提供给用户将会更好。实际上很多Blog引擎都提供了这种网址重写的功能，现在来看看这些是如何通过网址重写实现的。

　　首先，我们需要一个页面能够分别按照年、月、日分别显示Blog的内容。假定现在已经做好了一个页面文件ShowBlogContent.aspx，它能分别获取年、月、日的查询参数，要查看2004年2月14日所发的帖子，我们可以访问/ShowBlogContent.aspx?year=2004&month=2&day=14，要浏览2004年2月的数据可以访问/ShowBlogContent.aspx?year=2004&month=2，要查询2004年所有数据可以访问/ShowBlogContent.aspx?year=2004。（在下载文件中提供ShowBlogContent.aspx源代码。）

　　然后，当用户访问/2004/02/14.aspx时，我们需要将他访问的网址重写到/ShowBlogContent.aspx?year=2004&month=2&day=14上。这里需要制定三条网址重写规则：当指定访问年月日时、当指定访问年月时和当指定访问年时。

＜RewriterConfig＞
＜Rules＞
＜!-- Rules for Blog Content Displayer --＞
＜RewriterRule＞
＜LookFor＞~/(d{4})/(d{2})/(d{2}).aspx＜/LookFor＞
＜SendTo＞~/ShowBlogContent.aspx?year=$1&month=$2&day=$3＜/SendTo＞
＜/RewriterRule＞
＜RewriterRule＞
＜LookFor＞~/(d{4})/(d{2})/Default.aspx＜/LookFor＞
＜SendTo＞＜![CDATA[~/ShowBlogContent.aspx?year=$1&month=$2]]＞＜/SendTo＞
＜/RewriterRule＞
＜RewriterRule＞
＜LookFor＞~/(d{4})/Default.aspx＜/LookFor＞
＜SendTo＞~/ShowBlogContent.aspx?year=$1＜/SendTo＞
＜/RewriterRule＞
＜/Rules＞
＜/RewriterConfig＞

　　这些网址重写规则展示了正则表达式的强大威力。第一条规则按照(\d{4})/(\d{2})/(\d{2})\.aspx模式进行查找，通俗的说，它查找是否包含匹配xxxx/xx/xx.aspx格式的字符串，其中x表示数字，每一组数字必须用圆括号括起来，这样可以在相应＜SendTo＞节内引用圆括号内的匹配字符串。我们可以使用$1、$2、$3来分别引用前面匹配的圆括号组，其中$1，$2，$3分别表示所匹配的第一、第二、第三个圆括号组。

　　注意：由于web.config是XML格式的文档，所以在文本域内必须回避直接使用一些特殊字符，如：&，＜和＞符号等。在第一条网址重写规则的＜SendTo＞节中用&amp来表示引用&符号，在第二条网址重写规则的＜SendTo＞节中用＜![CDATA[...]]＞元素来表示其中所有的内容都是文本域，不再需要用转义字符来表示引用。这两种方法都可以实现同样的目的。

　　下面图五、图六、图七都显示出网址重写的运行状况。这些数据都真实地摘自作者的Blog，图五显示2003年11月7日的帖子，图六显示所有2003年11月的帖子，图七显示2003年所有帖子。


图五.显示2003年11月7日的帖子


图六. 显示2003年11月所有的帖子


图七. 显示2003年所有的帖子

　　注意：要使用网址重写引擎，强烈推荐在＜LookFor＞节中使用正则表达式。

创建必须的目录结构

　　当IIS接收到对/2004/03/19.aspx的请求时，他发现文件扩展名.aspx，便将该请求转交给ASP.NET引擎处理，在ASP.NET 引擎中传递时，该地址被重写到/ShowBlogContent.aspx?year=2004&month=3&day=19，最后用户将看到该Blog上2004年3月19日所有的帖子，但是在用户访问/2004/03/时会发生什么呢？除非已经存在一个/2004/01/的目录，否则IIS将返回一个404错误，而且该目录下还必须要有一个默认页面Default.aspx，IIS才能将请求转交给ASP.NET引擎处理。

　　通过这种方法你得手动为每一年的Blog创建一个年份的目录并在该年份下放置一个默认文件Default.aspx，而且还得在该年份目录下创建每一月的目录，从01、02、...、12，每一个目录下也要防止一个默认文件Default.aspx。（回想前面的例子，为了将/Products/重写到/ListCategories.aspx也是要建立一个/Products/目录并放置一个默认Default.aspx文件。

　　很明显，这样创建目录结构的过程是很痛苦的。解决这种问题的一个办法就是设置IIS将所有接收的请求都转交给ASP.NET引擎来处理，这种方法，甚至连访问这种地址/2004/04/，IIS都如实地将其转交给ASP.NET引擎处理，这种方法造成ASP.NET引擎得处理所有传入的请求，包括css文件，图片文件、Javascript文件以及Flash文件等等。

　　关于对所有类型文件的处理的详细讨论已经超出了本书范围。有关在ASP.NET Web应用程序中使用这些技术的例子请访问.Text 这个开源的Blog。.Text 可以通过配置将所有请求都转交给ASP.NET处理。它使用了一个自定义的HttpHandler来处理所有类型的文件类型，这个自定义的HttpHandler可以识别并判断如何处理所有的文件类型。（图像文件、CSS文件等等。）