.1. 概要
分析如何使用微软提供的ASP.NET来对动态产生的URL地址进行网址重写。网址重写是实现一种截取网址请求并将其进行处理后重新指向到一个指定的网址的过程。作者本人在对各种实现网址重写的技术进行研究和探讨后得出的经验和方法，希望能对您有所帮助。
1.6. 当一个请求传入ASP.NET引擎的时候会发生什么？
ASP.NET问世之前，在IIS Web服务器上的网址重写功能需要通过ISAPI过滤器来实现，自从这个家伙问世后我们就能通过ASP.NET来实现URL重写了，因为ASP.NET的解释引擎与IIS有极大的相似之处，产生这些相似性主要是因为ASP.NET：
· 在处理接收的请求的生命期内也会产生事件；
· 允许任意数量的HttpModule操控产生的事件，这与IIS中的ISAPI过滤器类似；
· 将请求的资源委托给HttpHandler处理，这与IIS中的ISAPI应用程序类似。
和IIS一样，在一个请求的整个生命期内，ASP.NET对该请求的处理状态发出的状态改变信号引发相应的事件。例如：BeginRequest事件在ASP.NET开始响应客户端请求之始引发；AuthenticateRequest事件在ASP.NET确立用户身份后引发，当然还有诸如AuthorizeRequest，ResolveRequestCache和EndRequest等其它很多事件，这些都是System.Web.HttpApplication类下的事件，更多信息请参考技术文档中的类HttpApplication概要（HttpApplication Class Overview）。
如上所述，可以创建ISAPI过滤器并用于相应IIS引发的事件，同理，ASP.NET也提供了HttpModule用于响应ASP.NET引擎引发的事件，一个ASP.NET应用程序通过配置可以拥有多个HttpModule。ASP.NET引擎每处理一个请求，便初始化一个相应配置好的HttpModule，并允许它针对请求处理期间引发的事件生成相应的事件委托。事实上ASP.NET引擎处理每一个请求调用大量的事件委托。FormsAuthenticationModule就是众多内嵌HttpModule中的一个，它首先检查是否使用表单授权，如果是的话，它将检查用户是否已授权，如果没有授权则自动把用户重定向到指定的登录页面。
回忆在IIS中，一项请求最后被转交给一个ISAPI应用程序处理，该应用程序针对每一项请求进行处理并返回相应的数据。例如，客户端发出一个访问经典ASP页面的请求，IIS将该请求转交给asp.dll程序处理，asp.dll针对该请求执行asp页面内容，并返回HTML编码。ASP.NET也使用了类似的手法，ASP.NET引擎在将这些HttpModule初始化后，判断并决定调用相应的HttpModule来处理该请求。
所有通过ASP.NET引擎解析的请求最终被送交一个HttpHandler或者HttpHandlerFactory（一个HttpHandler只是简单地返回一个用于处理该请求的HttpHandler的实例。）最终的委托呈现并响应所请求的HTML编码，并发送回IIS，IIS则将HTML返回给请求客户端。
ASP.NET包含许多HttpHandler，例如，PageHandlerFactory是用于呈现ASP.NET页面内容，WebServiceHandlerFactory用于呈现ASP.NET Web服务的SOAP数据包，TraceHandler用于将ASP.NET请求资源的HTML标记写入trace.axd。
图二描绘了一个针对ASP.NET资源的请求所经过的处理流程。首先，IIS接收到该请求并将其转交给aspnet_isapi.dll。其次，ASP.NET引擎将一些HttpModule初始化。最后，最终的HttpHandler被调用，生成相应的标记语言，并将其返回给IIS，最终返回到请求客户端。
图二．IIS和ASP.NET对请求的处理过程
1.7. 创建并注册自定义HttpModule和HttpHandler
创建自定义HttpModule的工作相对较简单，它包括一个实现当前接口的托管类，HttpModule必须实现System.Web.IHttpModule接口，同样HttpHandler和HttpHandlerFactory必须分别实现System.Web.IHttpHandler接口和System.Web.IhttpHandlerFactory接口。有关创建HttpHandler和HttpModule的细节已经超出本书范围，要了解更多详情请参阅Mansoor Ahmed Siddiqui的文章《HttpHandlers and HTTP modules in ASP.NET》（ASP.NET中的HttpHandler和HttpModule）。
一旦HttpModule和HttpHandler被创建后，必须向Web应用程序注册。如果要向整个Web服务器HttpModule和HttpHandler只需简单的写入machine.config文件；如果是由指定的Web应用程序调用则需在该程序的web.config配置文件中添加几行XML标记。
例如，要向指定的Web应用程序注册HttpModule和HttpHandler，只需向该Web应程序的web.config配置文件中configuration\System.Web节中添加下列几行：
1.10. 使用HttpModule来调用网址重写
在ASP.NET一级来执行网址重写，既可以使用HttpHandler，也可以使用HttpModule。当使用HttpModule的时候，必须决定如果该网址需要被重写的话，究竟应该在整个请求的生命周期期间的那一个点来使用。乍一看着有些武断，但是这个决定以重大而且微妙的方式影响到你的应用程序。之所以作出对网址重写点的选择是因为内嵌的ASP.NET HttpModule使用Request对象的属性值来完成自己的工作（回忆一下重写路径对Request对象的属性值的改变），这些内嵌HttpModule和相应事件的密切关系列举如下：
分析如何使用微软提供的ASP.NET来对动态产生的URL地址进行网址重写。网址重写是实现一种截取网址请求并将其进行处理后重新指向到一个指定的网址的过程。作者本人在对各种实现网址重写的技术进行研究和探讨后得出的经验和方法，希望能对您有所帮助。
1.2. 内容简介
稍微花点时间看一看你做的网站里头的URL地址，你看到类似这样的地址吗[url]http://yoursite.com/info/dispEmployeeInfo.aspx?EmpID=459-099&type=summary[/url] ？也许你会出于某种目的把大量的页面文件从一个目录甚至一个网站转移到其他地方，而许多访问者出于个人兴趣或者研究目的之前就已经将原有网址收藏了起来， 如果这时他从收藏夹打开该页面的时候发现这已经是坏链了。本文旨在介绍如何使用网址重写将那些“难看”的网址转换成比较有实际意义的网址，使其便于记忆。例如将[url]http://yoursite.com/info/dispEmployeeInfo.aspx?EmpID=459-099&type=summary[/url]转换成如下地址：[url]http://yoursite.com/[/url] dispEmployeeInfo/459-099/summary.html 。我们甚至发现网址重写技术可以解决令人头疼的404错误，或者说它可以创建一个智能化的404错误解决方案。
如上所述，网址重写是实现一种截取网址请求并将其进行处理后重新指向到一个指定的网址的过程。在网址重写执行的期间，相应处理程序处理被请求的网址，从中提取出相关的值，然后重新指向一个新的指定地址。例如：由于一次网站目录调整，原有的 /people/ 子目录下的所有网页全部移动到/info/employees/目录，原访问者从收藏夹或者其他什么地方点击链接发出访问/people/目录下的文件的请求时，你肯定希望他还是能通过原有地址看到和原来相同的页面，但实际上看到的却是网址重写指向的新目录下的相应文件。
在老版本ASP中，使用网址重写技术的途径很少，要么写一个ISAPI过滤器，要么购买第三方厂商提供的网址重写组件，然而在微软提供的ASP.NET下你可以通过多种方法很简单地开发出自己的网址重写软件，以满足自己各种不同的需要。本文将和你一起讨论这门针对ASP.NET开发人员的实现网址重写的技术，然后举一些网址重写实际应用的例子。在我们深入探讨网址重写技术的细节之前，我们先看一下日常使用网址重写技术实现的场景。
稍微花点时间看一看你做的网站里头的URL地址，你看到类似这样的地址吗[url]http://yoursite.com/info/dispEmployeeInfo.aspx?EmpID=459-099&type=summary[/url] ？也许你会出于某种目的把大量的页面文件从一个目录甚至一个网站转移到其他地方，而许多访问者出于个人兴趣或者研究目的之前就已经将原有网址收藏了起来， 如果这时他从收藏夹打开该页面的时候发现这已经是坏链了。本文旨在介绍如何使用网址重写将那些“难看”的网址转换成比较有实际意义的网址，使其便于记忆。例如将[url]http://yoursite.com/info/dispEmployeeInfo.aspx?EmpID=459-099&type=summary[/url]转换成如下地址：[url]http://yoursite.com/[/url] dispEmployeeInfo/459-099/summary.html 。我们甚至发现网址重写技术可以解决令人头疼的404错误，或者说它可以创建一个智能化的404错误解决方案。
如上所述，网址重写是实现一种截取网址请求并将其进行处理后重新指向到一个指定的网址的过程。在网址重写执行的期间，相应处理程序处理被请求的网址，从中提取出相关的值，然后重新指向一个新的指定地址。例如：由于一次网站目录调整，原有的 /people/ 子目录下的所有网页全部移动到/info/employees/目录，原访问者从收藏夹或者其他什么地方点击链接发出访问/people/目录下的文件的请求时，你肯定希望他还是能通过原有地址看到和原来相同的页面，但实际上看到的却是网址重写指向的新目录下的相应文件。
在老版本ASP中，使用网址重写技术的途径很少，要么写一个ISAPI过滤器，要么购买第三方厂商提供的网址重写组件，然而在微软提供的ASP.NET下你可以通过多种方法很简单地开发出自己的网址重写软件，以满足自己各种不同的需要。本文将和你一起讨论这门针对ASP.NET开发人员的实现网址重写的技术，然后举一些网址重写实际应用的例子。在我们深入探讨网址重写技术的细节之前，我们先看一下日常使用网址重写技术实现的场景。
1.3. 网址重写的一般用途
创建一个数据操作的ASP.NET程序最常见的就是一个aspx页面后面带上一些查询参数集合。例如在设计一个电子商务网站的时候，假定你设计了一项功能允许用户浏览待售的商品，为了更加方便操作，你设计了一个页面displayCategory.aspx将商品按照给定的分类显示，那么该分类下的商品显示页面上应该在页面文件对应网址后面加上了一个商品分类的查询参数，例如用户要查询待售的“装饰品”，在数据库中所有的装饰品数据对应的分类编号CategoryID的值为5，那么用户会访问如下网址：[url]http://yoursite.com/displayCategory.aspx?CategoryID=5[/url]。
创建一个包含类似这样网址的网站最终有两种结果，首先从最终用户的角度来观察，[url]http://yoursite.com/displayCategory.aspx?CategoryID=5[/url] 这个网址有些杂乱，可行性分析专家Jakob Neilson（主页：[url]http://useit.com/[/url]） 建议选择网址显示方式时候考虑如下要求（参考网址：[url]http://www.useit.com/alertbox/990321.html[/url]）：
● 是否简短
● 是否易于输入
● 是否将站点结构形象化
● 是否具有隐蔽性，也就是让用户通过一个虚拟的看似有意义的导航地址访问指向该地址
我想还应该在上述列表中再增加一条：是否便于记忆。[url]http://yoursite.com/displayCategory.aspx?CategoryID=5[/url] 这个地址没有一个地方符合Neilson标准的任何一条，也不便于记忆。当然，对于有经验的网络开发专家来说，他们很熟悉这种键值对构成的查询参数结构体系，然而对于普通用户来说输入这些带有参数的网址实在是太麻烦了。
一种较好的方法就是使用一种比较直观且容易记忆的方式来将网址表示为：[url]http://yoursite.com/products/Widgets[/url] 乍一看很容易就会推断这个网址所对应的内容极有可能会是显示装饰品（Widgets）信息，这个网址就变得更加容易记忆和传播！然后我告诉我的同事：“请查看这个网址：[url]http://yoursite.com/products/widgets[/url] ”不用我说第二遍，她可能一次就把地址敲到浏览器上了（你也可以在亚马逊（Amazon.com）的网站上这样尝试一下）。很快就浏览器上就列出了装饰品（Widgets）的内容。这里“隐蔽性”表示：用户可以自行变更网址的结尾，例如输入：[url]http://yoursite.com/products[/url] 就能看到全部分类相关的商品列表或者列出所有相关商品分类目录列表。
注：用上述简单的变更网址内容的方法来构思一下如今的比较流行的Blog网站生成的网址。例如：要查询2004年1月28日所发的帖子，只需输入 [url]http://someblog.com/2004/01/28 [/url] 即可，如果将网址裁减为 [url]http://someblog.com/2004/01[/url] 则显示 2004年1月份的帖子 ，同样将月份裁减掉得到 [url]http://someblog.com/2004[/url] 则显示出2004年全年所发的帖子。
网址重写技术除了用于将复杂的网址简单化之外，它还能用于处理因网站目录调整或者其他原因导致产生大量的无效链接和过期书签。
1.4. 当一个Web请求传送到IIS会发生什么？
在探讨如何实现网址重写这项技术之前，很有必要了解一下IIS是处理所接收的Web请求的机制。当一个Web请求到达IIS Web服务器时，IIS会根据所请求的文件后缀名来决定如何处理该请求，IIS可以处理诸如HTML页面、图片、静态内容，或者将请求转发给ISAPI应用程序，由该ISAPI应用程序处理后生成HTML静态内容返回给IIS，最后由IIS将请求结果发送回给客户端。（一个ISAPI应用程序就是一套编译好能随时在后台运行的类库，它的任务就是根据请求生成相关的内容。）
例如：如果IIS接收到一个对Info.asp的请求，它会将该请求转交给asp.dll来处理，该ISAPI应用程序调出并执行所请求的ASP页面，然后把生成的HTML代码返回给IIS，IIS最后把内容发送回请求客户端。对于ASP.NET页面，IIS则将请求转交给名为aspnet_isapi.dll的ISAPI应用程序来处理，该ISAPI应用程序调用托管的ASP.NET工作进程来处理该请求，并将生成的HTML代码返回给请求客户端。
你可以自定义IIS，将某一类扩展名映射到指定的ISAPI应用程序，图一显示了IIS管理工具中的应用程序配置对话框。
创建一个数据操作的ASP.NET程序最常见的就是一个aspx页面后面带上一些查询参数集合。例如在设计一个电子商务网站的时候，假定你设计了一项功能允许用户浏览待售的商品，为了更加方便操作，你设计了一个页面displayCategory.aspx将商品按照给定的分类显示，那么该分类下的商品显示页面上应该在页面文件对应网址后面加上了一个商品分类的查询参数，例如用户要查询待售的“装饰品”，在数据库中所有的装饰品数据对应的分类编号CategoryID的值为5，那么用户会访问如下网址：[url]http://yoursite.com/displayCategory.aspx?CategoryID=5[/url]。
创建一个包含类似这样网址的网站最终有两种结果，首先从最终用户的角度来观察，[url]http://yoursite.com/displayCategory.aspx?CategoryID=5[/url] 这个网址有些杂乱，可行性分析专家Jakob Neilson（主页：[url]http://useit.com/[/url]） 建议选择网址显示方式时候考虑如下要求（参考网址：[url]http://www.useit.com/alertbox/990321.html[/url]）：
● 是否简短
● 是否易于输入
● 是否将站点结构形象化
● 是否具有隐蔽性，也就是让用户通过一个虚拟的看似有意义的导航地址访问指向该地址
我想还应该在上述列表中再增加一条：是否便于记忆。[url]http://yoursite.com/displayCategory.aspx?CategoryID=5[/url] 这个地址没有一个地方符合Neilson标准的任何一条，也不便于记忆。当然，对于有经验的网络开发专家来说，他们很熟悉这种键值对构成的查询参数结构体系，然而对于普通用户来说输入这些带有参数的网址实在是太麻烦了。
一种较好的方法就是使用一种比较直观且容易记忆的方式来将网址表示为：[url]http://yoursite.com/products/Widgets[/url] 乍一看很容易就会推断这个网址所对应的内容极有可能会是显示装饰品（Widgets）信息，这个网址就变得更加容易记忆和传播！然后我告诉我的同事：“请查看这个网址：[url]http://yoursite.com/products/widgets[/url] ”不用我说第二遍，她可能一次就把地址敲到浏览器上了（你也可以在亚马逊（Amazon.com）的网站上这样尝试一下）。很快就浏览器上就列出了装饰品（Widgets）的内容。这里“隐蔽性”表示：用户可以自行变更网址的结尾，例如输入：[url]http://yoursite.com/products[/url] 就能看到全部分类相关的商品列表或者列出所有相关商品分类目录列表。
注：用上述简单的变更网址内容的方法来构思一下如今的比较流行的Blog网站生成的网址。例如：要查询2004年1月28日所发的帖子，只需输入 [url]http://someblog.com/2004/01/28 [/url] 即可，如果将网址裁减为 [url]http://someblog.com/2004/01[/url] 则显示 2004年1月份的帖子 ，同样将月份裁减掉得到 [url]http://someblog.com/2004[/url] 则显示出2004年全年所发的帖子。
网址重写技术除了用于将复杂的网址简单化之外，它还能用于处理因网站目录调整或者其他原因导致产生大量的无效链接和过期书签。
1.4. 当一个Web请求传送到IIS会发生什么？
在探讨如何实现网址重写这项技术之前，很有必要了解一下IIS是处理所接收的Web请求的机制。当一个Web请求到达IIS Web服务器时，IIS会根据所请求的文件后缀名来决定如何处理该请求，IIS可以处理诸如HTML页面、图片、静态内容，或者将请求转发给ISAPI应用程序，由该ISAPI应用程序处理后生成HTML静态内容返回给IIS，最后由IIS将请求结果发送回给客户端。（一个ISAPI应用程序就是一套编译好能随时在后台运行的类库，它的任务就是根据请求生成相关的内容。）
例如：如果IIS接收到一个对Info.asp的请求，它会将该请求转交给asp.dll来处理，该ISAPI应用程序调出并执行所请求的ASP页面，然后把生成的HTML代码返回给IIS，IIS最后把内容发送回请求客户端。对于ASP.NET页面，IIS则将请求转交给名为aspnet_isapi.dll的ISAPI应用程序来处理，该ISAPI应用程序调用托管的ASP.NET工作进程来处理该请求，并将生成的HTML代码返回给请求客户端。
你可以自定义IIS，将某一类扩展名映射到指定的ISAPI应用程序，图一显示了IIS管理工具中的应用程序配置对话框。
关于对IIS如何管理所接收的请求的详细探讨有些超出本文内容，想了解的更详细的话可以参考Michele Leroux Bustamante的著作Inside IIS and ASP.NET（深入研究IIS与ASP.NET），重要的是要了解ASP.NET引擎只负责处理对扩展名已经被正确配置映射到aspnet_isapi.dll的网络请求。
1.5. 用ISAPI过滤器来分析请求
除了将请求的文件扩展名映射到相应的ISAPI应用程序外，IIS还执行一些其他工作。例如IIS还主动对发出请求的客户端用户进行授权，并判断已授权用户是否对其请求的文件拥有访问权限，在一个请求过程的全部生命期内，IIS的处理经历了几个阶段，在每一个阶段IIS都生成一个事件，而该事件可以被ISAPI过滤器实时操控的。
如同ISAPI应用程序一样，ISAPI过滤器也是一块块安装在Web服务器上的非托管代码。ISAPI应用程序用于对所接收的特定文件类型做出响应，而ISAPI过滤器含有对IIS生成的事件做出响应的代码（contain Code），甚至可以编辑进出的数据。ISAPI也含有众多应用程序，包括：
· 权限控制与授权（Authentication and Authorization）
· 日志记录与监视（Logging and Monitoring）
· HTTP内容压缩（HTTP Compression）
· 网址重写（URL Rewriting）
本文所探讨的用ASP.NET实现的网址重写技术就是基于ISAPI过滤器用于网址重写的技术内容，然而我们仍然要讨论一下究竟是使用ISAPI过滤器还是使用ASP.NET应用程序提供的技术来实现网址重写技术。
除了将请求的文件扩展名映射到相应的ISAPI应用程序外，IIS还执行一些其他工作。例如IIS还主动对发出请求的客户端用户进行授权，并判断已授权用户是否对其请求的文件拥有访问权限，在一个请求过程的全部生命期内，IIS的处理经历了几个阶段，在每一个阶段IIS都生成一个事件，而该事件可以被ISAPI过滤器实时操控的。
如同ISAPI应用程序一样，ISAPI过滤器也是一块块安装在Web服务器上的非托管代码。ISAPI应用程序用于对所接收的特定文件类型做出响应，而ISAPI过滤器含有对IIS生成的事件做出响应的代码（contain Code），甚至可以编辑进出的数据。ISAPI也含有众多应用程序，包括：
· 权限控制与授权（Authentication and Authorization）
· 日志记录与监视（Logging and Monitoring）
· HTTP内容压缩（HTTP Compression）
· 网址重写（URL Rewriting）
本文所探讨的用ASP.NET实现的网址重写技术就是基于ISAPI过滤器用于网址重写的技术内容，然而我们仍然要讨论一下究竟是使用ISAPI过滤器还是使用ASP.NET应用程序提供的技术来实现网址重写技术。
1.6. 当一个请求传入ASP.NET引擎的时候会发生什么？
ASP.NET问世之前，在IIS Web服务器上的网址重写功能需要通过ISAPI过滤器来实现，自从这个家伙问世后我们就能通过ASP.NET来实现URL重写了，因为ASP.NET的解释引擎与IIS有极大的相似之处，产生这些相似性主要是因为ASP.NET：
· 在处理接收的请求的生命期内也会产生事件；
· 允许任意数量的HttpModule操控产生的事件，这与IIS中的ISAPI过滤器类似；
· 将请求的资源委托给HttpHandler处理，这与IIS中的ISAPI应用程序类似。
和IIS一样，在一个请求的整个生命期内，ASP.NET对该请求的处理状态发出的状态改变信号引发相应的事件。例如：BeginRequest事件在ASP.NET开始响应客户端请求之始引发；AuthenticateRequest事件在ASP.NET确立用户身份后引发，当然还有诸如AuthorizeRequest，ResolveRequestCache和EndRequest等其它很多事件，这些都是System.Web.HttpApplication类下的事件，更多信息请参考技术文档中的类HttpApplication概要（HttpApplication Class Overview）。
如上所述，可以创建ISAPI过滤器并用于相应IIS引发的事件，同理，ASP.NET也提供了HttpModule用于响应ASP.NET引擎引发的事件，一个ASP.NET应用程序通过配置可以拥有多个HttpModule。ASP.NET引擎每处理一个请求，便初始化一个相应配置好的HttpModule，并允许它针对请求处理期间引发的事件生成相应的事件委托。事实上ASP.NET引擎处理每一个请求调用大量的事件委托。FormsAuthenticationModule就是众多内嵌HttpModule中的一个，它首先检查是否使用表单授权，如果是的话，它将检查用户是否已授权，如果没有授权则自动把用户重定向到指定的登录页面。
回忆在IIS中，一项请求最后被转交给一个ISAPI应用程序处理，该应用程序针对每一项请求进行处理并返回相应的数据。例如，客户端发出一个访问经典ASP页面的请求，IIS将该请求转交给asp.dll程序处理，asp.dll针对该请求执行asp页面内容，并返回HTML编码。ASP.NET也使用了类似的手法，ASP.NET引擎在将这些HttpModule初始化后，判断并决定调用相应的HttpModule来处理该请求。
所有通过ASP.NET引擎解析的请求最终被送交一个HttpHandler或者HttpHandlerFactory（一个HttpHandler只是简单地返回一个用于处理该请求的HttpHandler的实例。）最终的委托呈现并响应所请求的HTML编码，并发送回IIS，IIS则将HTML返回给请求客户端。
ASP.NET包含许多HttpHandler，例如，PageHandlerFactory是用于呈现ASP.NET页面内容，WebServiceHandlerFactory用于呈现ASP.NET Web服务的SOAP数据包，TraceHandler用于将ASP.NET请求资源的HTML标记写入trace.axd。
图二描绘了一个针对ASP.NET资源的请求所经过的处理流程。首先，IIS接收到该请求并将其转交给aspnet_isapi.dll。其次，ASP.NET引擎将一些HttpModule初始化。最后，最终的HttpHandler被调用，生成相应的标记语言，并将其返回给IIS，最终返回到请求客户端。
图二．IIS和ASP.NET对请求的处理过程
1.7. 创建并注册自定义HttpModule和HttpHandler
创建自定义HttpModule的工作相对较简单，它包括一个实现当前接口的托管类，HttpModule必须实现System.Web.IHttpModule接口，同样HttpHandler和HttpHandlerFactory必须分别实现System.Web.IHttpHandler接口和System.Web.IhttpHandlerFactory接口。有关创建HttpHandler和HttpModule的细节已经超出本书范围，要了解更多详情请参阅Mansoor Ahmed Siddiqui的文章《HttpHandlers and HTTP modules in ASP.NET》（ASP.NET中的HttpHandler和HttpModule）。
一旦HttpModule和HttpHandler被创建后，必须向Web应用程序注册。如果要向整个Web服务器HttpModule和HttpHandler只需简单的写入machine.config文件；如果是由指定的Web应用程序调用则需在该程序的web.config配置文件中添加几行XML标记。
例如，要向指定的Web应用程序注册HttpModule和HttpHandler，只需向该Web应程序的web.config配置文件中configuration\System.Web节中添加下列几行：
<HttpModules>
<add type="type" name="name" />
</HttpModules>
其中type属性为HttpModule的标识号和类库名称，name属性则为该模块取一个较为友好的名称方便在Global.asax调用。
HttpHandler和HttpHandlerFactory则是在web.config文件中configuration\System.Web节中添加<httpHandler>标记，例如：
<add type="type" name="name" />
</HttpModules>
其中type属性为HttpModule的标识号和类库名称，name属性则为该模块取一个较为友好的名称方便在Global.asax调用。
HttpHandler和HttpHandlerFactory则是在web.config文件中configuration\System.Web节中添加<httpHandler>标记，例如：
<httpHandlers>
<add verb="verb" path="path" type="type" />
</HttpModules>
回忆上文，ASP.NET对每一个接收到的请求指派相应的HttpHandler来处理并呈现相应内容，该指派决定于所接收请求的verb和path的内容，verb为HTTP请求的类型：GET或者POST，path则为请求的文件的路径和文件名。如果我们打算用一个HttpHandler来处理所有GET类型和POST类型的并且文件扩展名为.scott的内容，可以在web.config相应配置节中加入下列标记：
<add verb="verb" path="path" type="type" />
</HttpModules>
回忆上文，ASP.NET对每一个接收到的请求指派相应的HttpHandler来处理并呈现相应内容，该指派决定于所接收请求的verb和path的内容，verb为HTTP请求的类型：GET或者POST，path则为请求的文件的路径和文件名。如果我们打算用一个HttpHandler来处理所有GET类型和POST类型的并且文件扩展名为.scott的内容，可以在web.config相应配置节中加入下列标记：
<httpHandlers>
<add varb="*" path=".scott" type="type" />
</httpHandlers>
其中type是我们定义的HttpHandler的类型。
注意：在注册HttpHandler的时候必须注意HttpHandler所使用的文件扩展名必须已经在IIS中做指向ASP.NET引擎的映射，在上面.scott扩展名的例子中，如果我们所使用的.scott扩展名如果没有在IIS中做指向ASP.NET引擎的映射的话，假定对foo.scott文件发出请求，该请求将导致IIS将foo.scott文件内容直接呈现给客户端，为了能够让HttpHandler处理该请求，必须将.scott扩展名在IIS中做指向ASP.NET引擎的映射，之后IIS才能正确地将.scott的请求转交给相应的HttpHandler。
有关HttpModule和HttpHandler更详细的内容请参阅MSDN中<HttpModules>节和<httpHandlers>节的文档信息。
<HttpModules>文档参考；
<httpHandlers>文档参考。
<add varb="*" path=".scott" type="type" />
</httpHandlers>
其中type是我们定义的HttpHandler的类型。
注意：在注册HttpHandler的时候必须注意HttpHandler所使用的文件扩展名必须已经在IIS中做指向ASP.NET引擎的映射，在上面.scott扩展名的例子中，如果我们所使用的.scott扩展名如果没有在IIS中做指向ASP.NET引擎的映射的话，假定对foo.scott文件发出请求，该请求将导致IIS将foo.scott文件内容直接呈现给客户端，为了能够让HttpHandler处理该请求，必须将.scott扩展名在IIS中做指向ASP.NET引擎的映射，之后IIS才能正确地将.scott的请求转交给相应的HttpHandler。
有关HttpModule和HttpHandler更详细的内容请参阅MSDN中<HttpModules>节和<httpHandlers>节的文档信息。
<HttpModules>文档参考；
<httpHandlers>文档参考。
1.8. 实现网址重写
网址重写技术不但可以在IIS Web服务器一级通过ISAPI过滤器实现，而且还可以在ASP.NET一级通过HttpModule或者HttpHandler实现。本文主要关注在ASP.NET一级实现网址重写技术，所以此时不必关注在ISAPI应用程序中实现网址重写的技术细节，而且有很多第三方厂商提供的ISAPI过滤器，比如
Helicon的ISAPI Rewrite；
QwerkSoft的IIS Rewrite；Port80的PageXChanger；
等等。
网址重写技术不但可以在IIS Web服务器一级通过ISAPI过滤器实现，而且还可以在ASP.NET一级通过HttpModule或者HttpHandler实现。本文主要关注在ASP.NET一级实现网址重写技术，所以此时不必关注在ISAPI应用程序中实现网址重写的技术细节，而且有很多第三方厂商提供的ISAPI过滤器，比如
Helicon的ISAPI Rewrite；
QwerkSoft的IIS Rewrite；Port80的PageXChanger；
等等。
1.9. 构建网址重写引擎
在ASP.NET中实现网址重写很简单，只需调用System.Web.HttpContext类的RewritePath()方法即可。HttpContext类中包含有关于特定HTTP请求的HTTP规范信息。ASP.NET引擎每接收到一个特定请求后便针对该请求创建一个特定的实例，这个类包含一些属性诸如：Request和Response属性，分别提供对请求和响应的访问；Application和Session属性提供对Application变量和Session变量的访问；User属性提供对已授权用户信息的访问。
在微软.NET Framework 1.0版本中，RewritePath()方法接收一个新路径的简单字符串，在其内部HttpContext类的RewritePath(string)方法内在地更新Request对象的路径和查询参数。除了RewritePath(string)方法之外，.NET Framework 1.1版还提供了另外一些重载版本，其中一个重载版本接收三个输入字符串参数，这种交替的重载形式不仅仅只是设置Request对象的路径和查询参数这些属性，而是设置更深层的成员变量，这些成员变量用于为PhysicalPath、PathInfo、FilePath属性计算Request对象值。
为了实现ASP.NET中的网址重写，我们需要创建一个HttpHandler和HttpModule用于：
根据请求的路径决定所需要重写的路径；
重写路径，如果需要的话可以调用RewritePath方法；
以前文所构建的那个站点为例，可以通过/info/employee.aspx?empID=EmployeeID来访问每一个雇员的信息。为了使这个网址更加地具有“隐蔽性”，我们可能会使用更加容易理解的访问方式如：/people/雇员名.aspx。这里就有了一个网址重写的案例：当接收到对/people/ScottMitchell.aspx的请求的时候，我们就得使用网址重写使得对该页面的请求被重写指向到先前使用的/info/employee?EmpID=1001地址。
在ASP.NET中实现网址重写很简单，只需调用System.Web.HttpContext类的RewritePath()方法即可。HttpContext类中包含有关于特定HTTP请求的HTTP规范信息。ASP.NET引擎每接收到一个特定请求后便针对该请求创建一个特定的实例，这个类包含一些属性诸如：Request和Response属性，分别提供对请求和响应的访问；Application和Session属性提供对Application变量和Session变量的访问；User属性提供对已授权用户信息的访问。
在微软.NET Framework 1.0版本中，RewritePath()方法接收一个新路径的简单字符串，在其内部HttpContext类的RewritePath(string)方法内在地更新Request对象的路径和查询参数。除了RewritePath(string)方法之外，.NET Framework 1.1版还提供了另外一些重载版本，其中一个重载版本接收三个输入字符串参数，这种交替的重载形式不仅仅只是设置Request对象的路径和查询参数这些属性，而是设置更深层的成员变量，这些成员变量用于为PhysicalPath、PathInfo、FilePath属性计算Request对象值。
为了实现ASP.NET中的网址重写，我们需要创建一个HttpHandler和HttpModule用于：
根据请求的路径决定所需要重写的路径；
重写路径，如果需要的话可以调用RewritePath方法；
以前文所构建的那个站点为例，可以通过/info/employee.aspx?empID=EmployeeID来访问每一个雇员的信息。为了使这个网址更加地具有“隐蔽性”，我们可能会使用更加容易理解的访问方式如：/people/雇员名.aspx。这里就有了一个网址重写的案例：当接收到对/people/ScottMitchell.aspx的请求的时候，我们就得使用网址重写使得对该页面的请求被重写指向到先前使用的/info/employee?EmpID=1001地址。
1.10. 使用HttpModule来调用网址重写
在ASP.NET一级来执行网址重写，既可以使用HttpHandler，也可以使用HttpModule。当使用HttpModule的时候，必须决定如果该网址需要被重写的话，究竟应该在整个请求的生命周期期间的那一个点来使用。乍一看着有些武断，但是这个决定以重大而且微妙的方式影响到你的应用程序。之所以作出对网址重写点的选择是因为内嵌的ASP.NET HttpModule使用Request对象的属性值来完成自己的工作（回忆一下重写路径对Request对象的属性值的改变），这些内嵌HttpModule和相应事件的密切关系列举如下：
HttpModule 事件 简介
FormsAuthenticationModule AuthenticateRequest 判断用户是否已通过表单授权方式获取授权，如果没有的话则将用户重定向到指定的登录页面
FileAuthorizationModule AuthorizeRequest 当使用Windows授权方式的时候，该HttpModule判断并确定该Microsoft Windows帐户是否对其请求的资源拥有足够的权限
UrlAuthorizationModule AuthorizeRequest 检查并确认请求者是否对所访问的网址拥有权限。该Url授权可以在web.config文件的<authorization>和<location>元素中配置
FormsAuthenticationModule AuthenticateRequest 判断用户是否已通过表单授权方式获取授权，如果没有的话则将用户重定向到指定的登录页面
FileAuthorizationModule AuthorizeRequest 当使用Windows授权方式的时候，该HttpModule判断并确定该Microsoft Windows帐户是否对其请求的资源拥有足够的权限
UrlAuthorizationModule AuthorizeRequest 检查并确认请求者是否对所访问的网址拥有权限。该Url授权可以在web.config文件的<authorization>和<location>元素中配置
回想一下BeginRequest事件在AuthenticateRequest事件之前引发，而AuthenticateRequest事件又在AuthorizeRequest事件之前引发。
实现网址重写的一个较为安全的场合就是把它放在在BeginRequest事件中执行，这意味着如果要执行网址重写的话，在众多内嵌HttpModule运行的时候他已经完成了。这种途径的最终用途淋漓尽致地体现在表单验证上。当用户访问受限资源的时候，如果之前使用了表单验证，他会自动被重定向到指定的登录页面，在成功登录之后，用户被重定向回先前试图访问的受限制页面。
如果把网址重写放在BeginRequest事件或者AuthenticateRequest事件中，在登录页面上执行提交后，该页面会将用户重定向到网址重写指定的页面。假定当用户在浏览器上敲入/people/ScottMitchell.aspx地址，该地址是要被重定向到/info/employee.aspx?EmpID=1001的，如果该Web应用程序设定使用表单验证，当用户开始访问/people/ScottMitchell.aspx的时候，该网址将重写指向/info/employee.aspx?EmpID=1001，接着ForumAuthenticationModule启动，如果需要的话将用户重定向到登录页面，用户登录后重定向到的页面将是/info/employee.aspx?EmpID=1001，这也是自从FormAuthenticationModule启动运行时所发出请求的页面。
同上类似，当把网址重写放在BeginRequest事件或者AuthenticateRequest事件中运行的时候，UrlAuthenticationModule也发现了网址重写指向的网址，这意味着如果在该应用程序的web.config文件中<location>节为特定的网址配置特定的授权地址的话，你得引用重写所指向的网址。
为了解决这个微妙的问题，一个可能就是把网址重写放在AuthorizeRequest事件中运行，但是在使用这种方法解决URL授权和表单授权的异常时又引入了一个新的缺陷：文件授权会失效。当使用Windows验证的时候，FileAuthorizationModule检查并验证已通过验证的用户是否拥有足够的权限访问特定的ASP.NET页面。
假定有一群用户并没有Windows级别的访问权限访问C:\inetpub\wwwroot\info\employee.aspx，当这些用户试图访问/info/employee.aspx?EmpID=1001的时候，他们会得到未授权的错误，如果我们把网址重写放到AuthenticateRequest事件中运行，当FileAuthorizationModule验证该安全性设置的时候，他仍任人为被请求的文件是/people/ScottMitchell.aspx，而这时该网址已经被重写了，因此FileAuthorizationModule会直接放行，让用户看到了网址重写指向的内容：/info/employee.aspx?Empid=1001。
那么什么时候在HttpModule调用网址重写合适呢？他决定于所使用的验证方式，当然如果不使用验证方式的话，那么无论是在BeginRequest事件、AuthenticateRequest事件还是AuthorizeRequest事件中调用网址重写没有多大区别，如果使用表单验证方式并且不使用Windows验证方式的话，把网址重写放入AuthorizeRequest事件委托中调用既可，如果使用Windows验证方式的话，把这项功能放入BeginRequest事件或者AuthenticateRequest事件调用就行了。
实现网址重写的一个较为安全的场合就是把它放在在BeginRequest事件中执行，这意味着如果要执行网址重写的话，在众多内嵌HttpModule运行的时候他已经完成了。这种途径的最终用途淋漓尽致地体现在表单验证上。当用户访问受限资源的时候，如果之前使用了表单验证，他会自动被重定向到指定的登录页面，在成功登录之后，用户被重定向回先前试图访问的受限制页面。
如果把网址重写放在BeginRequest事件或者AuthenticateRequest事件中，在登录页面上执行提交后，该页面会将用户重定向到网址重写指定的页面。假定当用户在浏览器上敲入/people/ScottMitchell.aspx地址，该地址是要被重定向到/info/employee.aspx?EmpID=1001的，如果该Web应用程序设定使用表单验证，当用户开始访问/people/ScottMitchell.aspx的时候，该网址将重写指向/info/employee.aspx?EmpID=1001，接着ForumAuthenticationModule启动，如果需要的话将用户重定向到登录页面，用户登录后重定向到的页面将是/info/employee.aspx?EmpID=1001，这也是自从FormAuthenticationModule启动运行时所发出请求的页面。
同上类似，当把网址重写放在BeginRequest事件或者AuthenticateRequest事件中运行的时候，UrlAuthenticationModule也发现了网址重写指向的网址，这意味着如果在该应用程序的web.config文件中<location>节为特定的网址配置特定的授权地址的话，你得引用重写所指向的网址。
为了解决这个微妙的问题，一个可能就是把网址重写放在AuthorizeRequest事件中运行，但是在使用这种方法解决URL授权和表单授权的异常时又引入了一个新的缺陷：文件授权会失效。当使用Windows验证的时候，FileAuthorizationModule检查并验证已通过验证的用户是否拥有足够的权限访问特定的ASP.NET页面。
假定有一群用户并没有Windows级别的访问权限访问C:\inetpub\wwwroot\info\employee.aspx，当这些用户试图访问/info/employee.aspx?EmpID=1001的时候，他们会得到未授权的错误，如果我们把网址重写放到AuthenticateRequest事件中运行，当FileAuthorizationModule验证该安全性设置的时候，他仍任人为被请求的文件是/people/ScottMitchell.aspx，而这时该网址已经被重写了，因此FileAuthorizationModule会直接放行，让用户看到了网址重写指向的内容：/info/employee.aspx?Empid=1001。
那么什么时候在HttpModule调用网址重写合适呢？他决定于所使用的验证方式，当然如果不使用验证方式的话，那么无论是在BeginRequest事件、AuthenticateRequest事件还是AuthorizeRequest事件中调用网址重写没有多大区别，如果使用表单验证方式并且不使用Windows验证方式的话，把网址重写放入AuthorizeRequest事件委托中调用既可，如果使用Windows验证方式的话，把这项功能放入BeginRequest事件或者AuthenticateRequest事件调用就行了。
