ASP.NET 管道事件与HttpModule, HttpHandler简单理解
第一部分：转载自Artech IIS与ASP.NET管道
ASP.NET管道
以IIS 6.0为例，在工作进程w3wp.exe中，利用Aspnet_ispai.dll加载.NET运行时（如果.NET运行时尚未加载）。IIS 6引入了应用程序池的概念，一个工作进程对应着一个应用程序池。一个应用程序池可以承载一个或者多个Web应用，每个Web应用映射到一个IIS虚拟目录。与IIS 5.x一样，每一个Web应用运行在各自的应用程序域中。
如果HTTP.SYS接收到的HTTP请求是对该Web应用的第一次访问，当成功加载了运行时后，会通过AppDomainFactory为该Web应用创建一个应用程序域（AppDomain）。随后，一个特殊的运行时IsapiRuntime被加载。IsapiRuntime定义在程序集System.Web中，对应的命名空间为System.Web.Hosting。IsapiRuntime会接管该HTTP请求。
IsapiRuntime会首先创建一个IsapiWorkerRequest对象，用于封装当前的HTTP请求，并将该IsapiWorkerRequest对象传递给ASP.NET运行时：HttpRuntime，从此时起，HTTP请求正式进入了ASP.NET管道。根据IsapiWorkerRequest对象，HttpRuntime会创建用于表示当前HTTP请求的上下文（Context）对象：HttpContext。
随着HttpContext被成功创建，HttpRuntime会利用HttpApplicationFactory创建新的或者获取现有的HttpApplication对象。实际上，ASP.NET维护着一个HttpApplication对象池，HttpApplicationFactory从池中选取可用的HttpApplication用户处理HTTP请求，处理完毕后将其释放到对象池中。HttpApplicationFactory负责处理当前的HTTP请求。
在HttpApplication初始化过程中，会根据配置文件加载并初始化相应的HttpModule对象。对于HttpApplication来说，在它处理HTTP请求的不同的阶段会触发不同的事件（Event），而HttpModule的意义在于通过注册HttpApplication的相应的事件，将所需的操作注入整个HTTP请求的处理流程。ASP.NET的很多功能，比如身份验证、授权、缓存等，都是通过相应的HttpModule实现的。
而最终完成对HTTP请求的处理实现在另一个重要的对象中：HttpHandler。对于不同的资源类型，具有不同的HttpHandler。比如.aspx页对应的HttpHandler为System.Web.UI.Page，WCF的.svc文件对应的HttpHandler为System.ServiceModel.Activation.HttpHandler。上面整个处理流程如图7所示。
图7 ASP.NET 处理管道
HttpApplication
HttpApplication是整个ASP.NET基础架构的核心，它负责处理分发给它的HTTP请求。由于一个HttpApplication对象在某个时刻只能处理一个请求，只有完成对某个请求的处理后，HttpApplication才能用于后续的请求的处理。所以，ASP.NET采用对象池的机制来创建或者获取HttpApplication对象。具体来讲，当第一个请求抵达的时候，ASP.NET会一次创建多个HttpApplication对象，并将其置于池中，选择其中一个对象来处理该请求。当处理完毕，HttpApplication不会被回收，而是释放到池中。对于后续的请求，空闲的HttpApplication对象会从池中取出，如果池中所有的HttpApplication对象都处于繁忙的状态，ASP.NET会创建新的HttpApplication对象。
HttpApplication处理请求的整个生命周期是一个相对复杂的过程，在该过程的不同阶段会触发相应的事件。我们可以注册相应的事件，将我们的处理逻辑注入到HttpApplication处理请求的某个阶段。我们接下来介绍的HttpModule就是通过HttpApplication事件注册的机制实现相应的功能的。表1按照实现的先后顺利列出了HttpApplication在处理每一个请求时触发的事件名称。
表1
|
名称 |
描述 |
|
BeginRequest |
HTTP管道开始处理请求时，会触发BeginRequest事件 |
|
AuthenticateRequest，PostAuthenticateRequest |
ASP.NET先后触发这两个事件,使安全模块对请求进行身份验证 |
|
AuthorizeRequest，PostAuthorizeRequest |
ASP.NET先后触发这两个事件,使安全模块对请求进程授权 |
|
ResolveRequestCache，PostResolveRequestCache |
ASP.NET先后触发这两个事件，以使缓存模块利用缓存的直接对请求直接进程响应（缓存模块可以将响应内容进程缓存，对于后续的请求，直接将缓存的内容返回，从而提高响应能力）。 |
|
PostMapRequestHandler |
对于访问不同的资源类型，ASP.NET具有不同的HttpHandler对其进程处理。对于每个请求，ASP.NET会通过扩展名选择匹配相应的HttpHandler类型，成功匹配后，该实现被触发 |
|
AcquireRequestState，PostAcquireRequestState |
ASP.NET先后触发这两个事件，使状态管理模块获取基于当前请求相应的状态，比如SessionState |
|
PreRequestHandlerExecute，PostRequestHandlerExecute |
ASP.NET最终通过一请求资源类型相对应的HttpHandler实现对请求的处理，在实行HttpHandler前后，这两个实现被先后触发 |
|
ReleaseRequestState，PostReleaseRequestState |
ASP.NET先后触发这两个事件，使状态管理模块释放基于当前请求相应的状态 |
|
UpdateRequestCache，PostUpdateRequestCache |
ASP.NET先后触发这两个事件，以使缓存模块将HttpHandler处理请求得到的相应保存到输出缓存中 |
|
LogRequest，PostLogRequest |
ASP.NET先后触发这两个事件为当前请求进程日志记录 |
|
EndRequest |
整个请求处理完成后，EndRequest事件被触发 |
对于一个ASP.NET应用来说，HttpApplication派生于global.asax文件，我们可以通过创建global.asax文件对HttpApplication的请求处理行为进行定制。global.asax采用一种很直接的方式实现了这样的功能，这种方式既不是我们常用的方法重写（Method Overriding）或者事件注册，而是直接采用方法名匹配。在global.asax中，我们按照这样的方法命名规则进行事件注册：Application_{Event Name}。比如Application_BeginRequest方法用于处理HttpApplication的BeginRequest事件。如果通过VS创建一个global.asax文件，下面是默认的定义。
1: <%@ Application Language="C#" %>
2: <script runat="server">
3: void Application_Start(object sender, EventArgs e) {}
4: void Application_End(object sender, EventArgs e) {}
5: void Application_Error(object sender, EventArgs e) {}
6: void Session_Start(object sender, EventArgs e) {}
7: void Session_End(object sender, EventArgs e) {}
8: </script>
HttpModule
ASP.NET为创建各种.NET Web应用提供了强大的平台，它拥有一个具有高度可扩展性的引擎，并且能够处理对于不同资源类型的请求。那么，是什么成就了ASP.NET的高可扩展性呢？ HttpModule功不可没。
从功能上讲，HttpModule之于ASP.NET，就好比ISAPI Filter之于IIS一样。IIS将接收到的请求分发给相应的ISAPI Extension之前，注册的ISAPI Filter会先截获该请求。ISAPI Filter可以获取甚至修改请求的内容，完成一些额外的功能。与之相似地，当请求转入ASP.NET管道后，最终负责处理该请求的是与请求资源类型相匹配的HttpHandler对象，但是在Handler正式工作之前，ASP.NET会先加载并初始化所有配置的HttpModule对象。HttpModule在初始化的过程中，会将一些功能注册到HttpApplication相应的事件中，那么在HttpApplication整个请求处理生命周期中的某个阶段，相应的事件会被触发，通过HttpModule注册的事件处理程序也得以执行。
所有的HttpModule都实现了IHttpModule接口，下面是IHttpModule的定义。其中Init方法用于实现HttpModule自身的初始化，该方法接受一个HttpApplication对象，有了这个对象，事件注册就很容易了。
1: public interface IHttpModule
2: {
3: void Dispose();
4: void Init(HttpApplication context);
5: }
ASP.NET提供的很多基础构件（Infrastructure）功能都是通过相应的HttpModule实现的，下面类列出了一些典型的HttpModule:
- OutputCacheModule：实现了输出缓存（Output Caching）的功能；
- SessionStateModule：在无状态的HTTP协议上实现了基于会话（Session）的状态；
- WindowsAuthenticationModule + FormsAuthenticationModule + PassportAuthentication- Module：实现了3种典型的身份认证方式：Windows认证、Forms认证和Passport认证；
- UrlAuthorizationModule + FileAuthorizationModule：实现了基于Uri和文件ACL（Access Control List）的授权。
而另外一个重要的HttpModule与WCF相关，那么就是System.ServiceModel. Activation.HttpModule。HttpModule定义在System.ServiceModel程序集中，在默认的情况下，HttpModule完成了基于IIS的寄宿工作。
除了这些系统定义的HttpModule之外，我们还可以自定义HttpMoudle。通过Web.config，我们可以很容易地将其注册到我们的Web应用中。
HttpHandler
如果说HttpModule相当于IIS的ISAPI Filter的话，我们可以说HttpHandler则相当于IIS的ISAPI Extension，HttpHandler在ASP.NET中扮演请求的最终处理者的角色。对于不同资源类型的请求，ASP.NET会加载不同的Handler来处理，也就是说.aspx page与.asmx web service对应的Handler是不同的。
所有的HttpHandler都实现了接口IHttpHandler。下面是IHttpHandler的定义，方法ProcessRequest提供了处理请求的实现。
1: public interface IHttpHandler
2: {
3: void ProcessRequest(HttpContext context);
4: bool IsReusable { get; }
5: }
对于某些HttpHandler，具有一个与之相关的HttpHandlerFactory，用于创建或者获取相应的HttpHandler。HttpHandlerFactory实现接口IHttpHandlerFactory，方法GetHandler用于创建新的HttpHandler，或者获取已经存在的HttpHandler。
1: public interface IHttpHandlerFactory
2: {
3: IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated);
4: void ReleaseHandler(IHttpHandler handler);
5: }
HttpHandler和HttpHandlerFactory的类型都可以通过相同的方式配置到Web.config中。下面一段配置包含对3种典型的资源类型的HttpHandler配置：.aspx,.asmx和.svc。可以看到基于WCF Service的HttpHandler类型为：System.ServiceModel.Activation.HttpHandler。
1: <?xml version="1.0" encoding="utf-8" ?>
2: <configuration>
3: <system.web>
4: <httpHandlers>
5: <add path="*.svc" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" validate="false"/>
6: <add path="*.aspx" verb="*" type="System.Web.UI.PageHandlerFactory" validate="True"/>
7: <add path="*.asmx" verb="*" type="System.Web.Services.Protocols.WebServiceHandlerFactory, System.Web.Services, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" validate="False"/>
8: </httpHandlers>
9: </system.web>
10: </configuration>
第二部分：转自 HttpModule的认识
HttpModule是向实现类提供模块初始化和处置事件。当一个HTTP请求到达HttpModule时，整个ASP.NET Framework系统还并没有对这个HTTP请求做任何处理，也就是说此时对于HTTP请求来讲，HttpModule是一个HTTP请求的“必经之路”，所以可以在这个HTTP请求传递到真正的请求处理中心（HttpHandler）之前附加一些需要的信息在这个HTTP请求信息之上，或者针对截获的这个HTTP请求信息作一些额外的工作，或者在某些情况下干脆终止满足一些条件的HTTP请求，从而可以起到一个Filter过滤器的作用。
1、asp.net的HTTP请求处理过程
说明：
（1）、客户端浏览器向服务器发出一个http请求，此请求会被inetinfo.exe进程截获，然后转交给aspnet_isapi.dll进程，接着它又通过Http Pipeline的管道，传送给aspnet_wp.exe这个进程，接下来就到了.net framework的HttpRunTime处理中心，处理完毕后就发送给用户浏览器。
（2）、当一个http请求被送入到HttpRuntime之后，这个Http请求会继续被送入到一个被称之为HttpApplication Factory的一个容器当中，而这个容器会给出一个HttpApplication实例来处理传递进来的http请求，而后这个Http请求会依次进入到如下几个容器中：HttpModule --> HttpHandler Factory --> HttpHandler。当系统内部的HttpHandler的ProcessRequest方法处理完毕之后，整个Http Request就被处理完成了，客户端也就得到相应的东东了。
（3）完整的http请求在asp.net framework中的处理流程：
HttpRequest-->inetinfo.exe->ASPNET_ISAPI.DLL-->Http Pipeline-->ASPNET_WP.EXE-->HttpRuntime-->HttpApplication Factory-->HttpApplication-->HttpModule-->HttpHandler Factory-->HttpHandler-->HttpHandler.ProcessRequest()
也就是说一个HTTP请求在HttpModule容器的传递过程中，会在某一时刻（ResolveRequestCache事件）将这个HTTP请求传递给HttpHandler容器。在这个事件之后，HttpModule容器会建立一个HttpHandler的入口实例，但是此时并没有将HTTP请求控制权交出，而是继续触发AcquireRequestState事件以及PreRequestHandlerExcute事件。在PreRequestHandlerExcute事件之后，HttpModule窗口就会将控制权暂时交给HttpHandler容器，以便进行真正的HTTP请求处理工作。
而在HttpHandler容器内部会执行ProcessRequest方法来处理HTTP请求。在容器HttpHandler处理完毕整个HTTP请求之后，会将控制权交还给HttpModule，HttpModule则会继续对处理完毕的HTTP请求信息流进行层层的转交动作，直到返回到客户端为止。
PS:红色的HttpApplication实例在HttpModule的Init方法中会用到。
（4）如果想在中途截获一个httpRequest并做些自己的处理，就应该在HttpRuntime运行时内部来做到这一点，确切的说是在HttpModule这个容器中来实现。
2、HttpModule工作原理
负责监听HttpRequest，同时对HttpRequest增添或者过滤掉一部分内容。也就是说，当一个HTTP请求到达HttpModule时，整个ASP.NET Framework系统还并没有对这个HTTP请求做任何处理，也就是说此时对于HTTP请求来讲，HttpModule是一个HTTP请求的“必经之路”，所以可以在这个HTTP请求传递到真正的请求处理中心（HttpHandler）之前附加一些需要的信息在这个HTTP请求信息之上，或者针对截获的这个HTTP请求信息作一些额外的工作，或者在某些情况下干脆终止满足一些条件的HTTP请求，从而可以起到一个Filter过滤器的作用。
HttpModule实现了接口IHttpModule，我们可以自定义实现该接口的类，从而取代HttpModule。
asp.net默认的HttpModule如下：
System.Web.SessionState.SessionStateModule;
System.Web.Security.WindowsAuthenticationModule;
System.Web.Security.FormsAuthenticationModule;
System.Web.Security.PassportAuthenticationModule;
System.Web.Security.UrlAuthorizationModule;
System.Web.Security.FileAuthorizationModule;
3、编写自己的HttpModule
要实现HttpModule，必须实现接口IHttpModule。下面是IHttpModule接口分析：
using System;
namespace System.Web
{
public interface IHttpModule
{
// 销毁不再被HttpModule使用的资源
void Dispose();
// 初始化一个Module,为捕获HttpRequest做准备
void Init(HttpApplication context);
}
}
下面是自己的HttpModule：
using System;
using System.Web;
namespace ClassLibrary1
{
public class MyHttpModule : IHttpModule
{
public void Dispose() { }
public void Init(HttpApplication context)
{
context.BeginRequest += new EventHandler(Application_BeginRequest);
context.EndRequest += new EventHandler(Application_EndRequest);
}
public void Application_BeginRequest(object sender, EventArgs e)
{
HttpApplication application = sender as HttpApplication;
HttpContext context = application.Context;
HttpResponse response = context.Response;
response.Write("这是来自自定义HttpModule中有BeginRequest");
}
public void Application_EndRequest(object sender, EventArgs e)
{
HttpApplication application = sender as HttpApplication;
HttpContext context = application.Context;
HttpResponse response = context.Response;
response.Write("这是来自自定义HttpModule中有EndRequest");
}
}
}
web.config
<httpModules>
<add name="myHttpModule" type="ClassLibrary1.MyHttpModule,ClassLibrary1"/>
</httpModules>
default.aspx.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
Response.Write("<br/><br/>来自Default.aspx页面<br/>");
}
}
4、HttpModule内部事件机制和生命周期
HttpModule对HttpApplication实例进行处理，而HttpApplication有很多事件（对应不同的生命期），这样就衍生出HttpModule内部事件机制和生命周期。
（1）、HttpModule的事件
| BeginRequest | 指示请求处理开始 |
| AuthenticateRequest | 封装请求身份验证过程 |
| AuthorizeRequest | 封装检查是否能利用以前缓存的输出页面处理请求的过程 |
| ResolveRequestCache | 从缓存中得到相应时候触发 |
| AcquireRequestState | 加载初始化Session时候触发 |
| PreRequestHandlerExecute | 在Http请求进入HttpHandler之前触发 |
| PostRequestHandlerExecute | 在Http请求进入HttpHandler之后触发 |
| ReleaseRequestState | 存储Session状态时候触发 |
| UpdateRequestCache | 更新缓存信息时触发 |
| EndRequest | 在Http请求处理完成的时候触发 |
| PreSendRequestHenaders | 在向客户端发送Header之前触发 |
| PreSendRequestConternt | 在向客户端发送内容之前触发 |
说明：
a、BenginRequest和EndRequest分别是HttpModule容器最开始的和最后的事件；
b、EndRequest之后还会触发PreSendRequestHeaders事件和PreSendRequestContent事件，这不是在HttpModule外的两个事件，表示HttpModule结束，即将开始向Client发送数据。
（2）、验证HttpModule生命周期
与HttpHandler的交互：
说明：
a、HttpModule容器会将HttpRequest传递到HttpHandler容器，这个时间点是ResolveRequestCache事件
b、HttpModule容器会建立HttpHandler实例作为入口——Session从此生效
c、触发AcquireRequestState事件以及PreRequestHandlerExecute事件
d、HttpModule容器便将对HttpRequest的控制权转让给HttpHandler容器
e、HttpHandler容器处理HttpRequest——使用自身的ProcessRequest方法，将对其控制权又还给HttpModule容器——之后Session失效。
验证生命周期代码：
using System;
using System.Collections.Generic;
using System.Text;
using System.Web;
namespace MyHttpModule
{
public class ValidaterHttpModuleEvents : IHttpModule
{
public void Dispose()
{ }
/// <summary>
/// 验证HttpModule事件机制
/// </summary>
/// <param name="application"></param>
public void Init(HttpApplication application)
{
application.BeginRequest += new EventHandler(application_BeginRequest);
application.EndRequest += new EventHandler(application_EndRequest);
application.AcquireRequestState += new EventHandler(application_AcquireRequestState);
application.AuthenticateRequest += new EventHandler(application_AuthenticateRequest);
application.AuthorizeRequest += new EventHandler(application_AuthorizeRequest);
application.PreRequestHandlerExecute += new EventHandler(application_PreRequestHandlerExecute);
application.PostRequestHandlerExecute += new EventHandler(application_PostRequestHandlerExecute);
application.ReleaseRequestState += new EventHandler(application_ReleaseRequestState);
application.ResolveRequestCache += new EventHandler(application_ResolveRequestCache);
application.PreSendRequestHeaders += new EventHandler(application_PreSendRequestHeaders);
application.PreSendRequestContent += new EventHandler(application_PreSendRequestContent);
}
private void application_BeginRequest(object sender, EventArgs e)
{
HttpApplication application = (HttpApplication)sender;
application.Context.Response.Write("application_BeginRequest<br/>");
}
private void application_EndRequest(object sender, EventArgs e)
{
HttpApplication application = (HttpApplication)sender;
application.Context.Response.Write("application_EndRequest<br/>");
}
private void application_PreRequestHandlerExecute(object sender, EventArgs e)
{
HttpApplication application = (HttpApplication)sender;
application.Context.Response.Write("application_PreRequestHandlerExecute<br/>");
}
private void application_PostRequestHandlerExecute(object sender, EventArgs e)
{
HttpApplication application = (HttpApplication)sender;
application.Context.Response.Write("application_PostRequestHandlerExecute<br/>");
}
private void application_ReleaseRequestState(object sender, EventArgs e)
{
HttpApplication application = (HttpApplication)sender;
application.Context.Response.Write("application_ReleaseRequestState<br/>");
}
private void application_AcquireRequestState(object sender, EventArgs e)
{
HttpApplication application = (HttpApplication)sender;
application.Context.Response.Write("application_AcquireRequestState<br/>");
}
private void application_PreSendRequestContent(object sender, EventArgs e)
{
HttpApplication application = (HttpApplication)sender;
application.Context.Response.Write("application_PreSendRequestContent<br/>");
}
private void application_PreSendRequestHeaders(object sender, EventArgs e)
{
HttpApplication application = (HttpApplication)sender;
application.Context.Response.Write("application_PreSendRequestHeaders<br/>");
}
private void application_ResolveRequestCache(object sender, EventArgs e)
{
HttpApplication application = (HttpApplication)sender;
application.Context.Response.Write("application_ResolveRequestCache<br/>");
}
private void application_AuthorizeRequest(object sender, EventArgs e)
{
HttpApplication application = (HttpApplication)sender;
application.Context.Response.Write("application_AuthorizeRequest<br/>");
}
private void application_AuthenticateRequest(object sender, EventArgs e)
{
HttpApplication application = (HttpApplication)sender;
application.Context.Response.Write("application_AuthenticateRequest<br/>");
}
}
}
<add name="HttpModule1" type="MyHttpModule.HttpModule1,MyHttpModule"/>
<add name="HttpModule2" type="MyHttpModule.HttpModule2,MyHttpModule"/>
HttpModule1和HttpModule2模仿ValidaterHttpModuleEvents编写（除了类名改变外，事件和方法不变），不贴代码了。运行结果如下：
从运行结果可以看到，在web.config文件中引入自定义HttpModule的顺序就决定了多个自定义HttpModule在处理一个HTTP请求的接管顺序。
(3)、利用HttpModule实现终止此次HttpRequest请求
在BeginRequest事件中，使用HttpApplication.CompleteRequest()方法可以实现当满足一定条件时终止此次HttpRequest请求
using System;
using System.Web;
namespace ClassLibrary1
{
public class MyHttpModule : IHttpModule
{
public void Dispose() { }
public void Init(HttpApplication context)
{
context.BeginRequest += new EventHandler(Application_BeginRequest);
}
public void Application_BeginRequest(object sender, EventArgs e)
{
HttpApplication application = sender as HttpApplication;
application.CompleteRequest();
application.Context.Response.Write("请求被终止");
}
}
}
说明：
a、对于一个HttpModule，在BeginRquest中终止，但是仍然会调用EndRequest事件，以及PreSendRequestHeaders事件和PreSendRequestContent事件。也可以说是直接跳转到EndRequest事件，而不会调用这期间的事件
b、如果有两个HttpModule，在第一个HttpModule的BeginRequest中终止，仅仅不会调用第二个HttpModule的BeginRequest，但仍然会调用两个EndRequest事件，以及PreSendRequestHeaders事件和PreSendRequestContent事件。看下面的图示：
