阅读目录

• 开始

• 理解ASP.NET管线

• 理解HttpApplication

• 理解HttpHandler

• 理解HttpModule

• 三大对象的总结

• 案例演示

• 如何选择？

最近收到几个疑问：HttpHandler和HttpModule之间有什么差别，我到底该选择哪个？
之所以有这个疑问，是因为在这二类对象中都可以访问Request, Response对象，都能处理请求。

我原以为在博客 用Asp.net写自己的服务框架中做了那么多的演示应该把它们的使用方法说清楚了，然而有些人看了我的那些示例，仍然不知道该如何选择它们，为了实现同一个目标，我既用了HttpHandler，也有用HttpModule。现在看来，我当时设计的那些示例并不是讲清楚HttpHandler和HttpModule之间有什么差别，而是在演示如何利用HttpHandler和HttpModule设计一个服务框架。

很庆幸那篇博客内容没有走题，今天只好再来写一篇了。

本文约定：
1. HttpHandler泛指所有实现IHttpHandler接口的类型。
2. HttpModule泛指所有实现IHttpModule接口的类型。
因此，本文将不会特别区分这些类型与接口。

回到顶部

理解ASP.NET管线

HttpHandler和HttpModule，它们都与ASP.NET管线有关，所以我想理解这二类对象必须要理解ASP.NET管线的工作方式。

下图反映了ASP.NET管线的处理流程：

这是一张时序图，我们应该从二个角度来理解它：
1. 有哪些调用动作。
2. 有哪些参与者。

每个调用动作，都反映了ASP.NET管线的处理阶段，它们会引发相应的事件（除GetHandler,ProcessRequest之外），HttpModule则会订阅这些事件，参与到管线处理过程。这些阶段中，有些阶段还引发了二个事件，完整的管线事件可参考MSDN文档：

在处理该请求时将由 HttpApplication 类执行以下事件。 希望扩展 HttpApplication 类的开发人员尤其需要注意这些事件。
1. 对请求进行验证，将检查浏览器发送的信息，并确定其是否包含潜在恶意标记。 有关更多信息，请参见 ValidateRequest 和脚本侵入概述。
2. 如果已在 Web.config 文件的 UrlMappingsSection 节中配置了任何 URL，则执行 URL 映射。
3. 引发 BeginRequest 事件。
4. 引发 AuthenticateRequest 事件。
5. 引发 PostAuthenticateRequest 事件。
6. 引发 AuthorizeRequest 事件。
7. 引发 PostAuthorizeRequest 事件。
8. 引发 ResolveRequestCache 事件。
9. 引发 PostResolveRequestCache 事件。
10. 根据所请求资源的文件扩展名（在应用程序的配置文件中映射），选择实现 IHttpHandler 的类，对请求进行处理。 如果该请求针对从 Page 类派生的对象（页），并且需要对该页进行编译，则 ASP.NET 会在创建该页的实例之前对其进行编译。
11. 引发 PostMapRequestHandler 事件。
12. 引发 AcquireRequestState 事件。
13. 引发 PostAcquireRequestState 事件。
14. 引发 PreRequestHandlerExecute 事件。
15. 为该请求调用合适的 IHttpHandler 类的 ProcessRequest 方法（或异步版 IHttpAsyncHandler.BeginProcessRequest）。 例如，如果该请求针对某页，则当前的页实例将处理该请求。
16. 引发 PostRequestHandlerExecute 事件。
17. 引发 ReleaseRequestState 事件。
18. 引发 PostReleaseRequestState 事件。
19. 如果定义了 Filter 属性，则执行响应筛选。
20. 引发 UpdateRequestCache 事件。
21. 引发 PostUpdateRequestCache 事件。
22. 引发 EndRequest 事件。
23. 引发 PreSendRequestHeaders 事件。
24. 引发 PreSendRequestContent 事件。

图片中还反映了ASP.NET的三种主要的参与者：
1. HttpModule
2. HttpHandlerFactory
3. HttpHandler

有没有有想过：这三种参与者中，每种有多少个参与对象呢？

为了清楚地回答这个问题，我准备了下面的表格：

为什么要引入HttpHandlerFactory呢？ 请看我的博客 细说 HttpHandler 的映射过程，今天就不重复这块内容了。

除开HttpHandlerFactory，我们可以发现：在ASP.NET管线中，HttpHandler应该只有一个，而HttpModule是可选的。
进而，我们是不是可以这样理解：HttpHandler才是处理请求的主角（不可缺少），HttpModule是配角（可以没有）？

回到顶部

理解HttpApplication

前面我们一直在说ASP.NET管线，那么，谁在控制管线过程？
答案是：HttpApplication对象。
1. HttpApplication细分它的处理过程，在不同阶段引发不同的事件，使得HttpModule通过订阅事件的方式加入到请求的处理过程中。
2. 在请求的处理过程中，HttpApplication对象主要扮演着控制处理流程的推进作用。
3. HttpApplication会在固定的阶段获取一个IHttpHandler实例，然后将请求的响应过程交给具体的IHttpHandler来实现。

HttpApplication如何产生，如何工作？
1. HttpApplication对象会被重用，当HttpRuntime不能从HttpApplicationFactory获取空闲的实例时，才会创建。
2. HttpRuntime会将每个请求交给一个HttpApplication对象来处理。
3. HttpApplication对象在初始化时负责加载全部的HttpModule。
4. 每个HttpApplication对象会控制属于它的管线过程（前面已解释）。

HttpApplication是个非常重要的类型，它的许多功能都属于框架的基础部分，不需要我们调用，因此，我们平时不会用到它。

我不想让博客走题，下面来看看今天的主角吧。

回到顶部

理解HttpHandler

前面说到HttpRuntime会将请求交给HttpApplication来处理，此时你有没有想过这样一个问题：为什么HttpApplication不直接处理请求，而是要再交给一个HttpHandler对象来处理呢？

答案是：每个请求的内容可能并不相同，它们存在多样性，因此ASP.NET采用了抽象工厂模式来处理这些请求。ASP.NET在web.config的架构中，允许我们指定某些请求映射到一个HttpHandlerFactory，例如：

<!--适用于IIS6的配置--><system.web>    <httpHandlers>        <add path="*.cspx" verb="*" type="MyMVC.AjaxHandlerFactory, MyMVC" validate="true" />        <add path="*.aspx" verb="*" type="MyMVC.MvcPageHandlerFactory, MyMVC" validate="true" />        <add path="/mvc/*" verb="*" type="MyMVC.MvcPageHandlerFactory, MyMVC" validate="true" />    </httpHandlers></system.web><!--适用于IIS7的配置（集成模式）--><system.webServer>    <handlers>        <add name="AjaxHandlerFactory" verb="*" path="*.cspx" type="MyMVC.AjaxHandlerFactory, MyMVC" preCondition="integratedMode" />        <add name="MvcPageHandlerFactory" verb="*" path="*.aspx" type="MyMVC.MvcPageHandlerFactory, MyMVC" preCondition="integratedMode" />        <add name="MvcPageHandlerFactory2" verb="*" path="/mvc/*" type="MyMVC.MvcPageHandlerFactory, MyMVC" preCondition="integratedMode" />    </handlers></system.webServer>

当某个请求与一个规则匹配后，ASP.NET会调用匹配的HttpHandlerFactory的GetHandler方法来获取一个HttpHandler实例，最后由一个HttpHandler实例来处理当前请求。

HttpApplication是如何将请求交给HttpHandler实例来处理的呢？
为了理解这个过程，我们要来看一下IHttpHandler接口的定义：

// 这个接口用于同步调用// 异步版本的接口用法请参考：http://www.cnblogs.com/fish-li/archive/2011/11/20/2256385.htmlpublic interface IHttpHandler{    // 获取一个值，该值指示其他请求是否可以使用 IHttpHandler 实例。    bool IsReusable { get; }    // 通过实现 IHttpHandler 接口的自定义 HttpHandler 启用 HTTP Web 请求的处理。    void ProcessRequest(HttpContext context);}

HttpApplication在将某个请求交给HttpHandler实例来处理时，是通过接口来调用的（ProcessRequest方法）。

与HttpHandler的相关话题：
1.  异步 HttpHandler：细说ASP.NET的各种异步操作。
2.  如何重用HttpHandler：细说 HttpHandler 的映射过程。

HttpHanlder的典型应用

<%@ WebHandler Language="C#" Class="Login" %>using System;using System.Web;public class Login : IHttpHandler {        public void ProcessRequest (HttpContext context) {        context.Response.ContentType = "text/plain";        string username = context.Request.Form["name"];        string password = context.Request.Form["password"];        if( password == "aaaa" ) {            System.Web.Security.FormsAuthentication.SetAuthCookie(username, false);            context.Response.Write("OK");        }        else {            context.Response.Write("用户名或密码不正确。");        }    }

通常我去这样创建一个ashx文件（HttpHanlder）响应某种特殊的请求。
所以，我们应该这样理解HttpHanlder：一个HttpHanlder用于响应一类特定的请求。

我们经常用到的HttpHanlder有哪些？

1. aspx页面。
2. asmx服务文件。
3. ashx文件（一般处理程序）。
4. 实现IHttpHandler接口的自定义类型。

我们通常使用HttpHanlder做什么？

注意观察表格中实现目标，我们可以得到一个结论：使用HttpHanlder的目的是生成响应结果。

回到顶部

理解HttpModule

设计HttpHanlder的目的很明确：生成响应结果。
那么，设计HttpModule又是为什么呢？

前面说过，一个HttpHanlder用于处理一类特定的请求，每个aspx, ashx都可以认为是一类请求。有时候我们发现所有页面可能都需要某些相同的检查功能（如身份检查），假如只能使用HttpHanlder，那我们就要让所有页面都去调用那些相同的检查功能。谁愿意做这些重复的事情？或许有些人会回答，可以自己实现一个基类，把检查功能放在基类中去调用。然而，这种做法只能解决重复调用问题，它会让代码失去灵活性（扩展性），试想一下：如果需要再加入新的检查功能，或者用新的检查方法替换原有的检查逻辑时怎么办？只能是修改基类了吧？

设计HttpModule的目的正是为了提供一个灵活的方法解决这种功能重用问题。它采用事件（观察者）的设计模式，将某些HttpHanlder都需要的功能抽取出来，形成不同的观察者类型，这些观察者类型可以编译成类库形式，供多个网站项目共用。为了让ASP.NET管线更灵活，ASP.NET允许我们在web.config中自由配置需要的HttpModule，例如：

<!--适用于IIS6的配置--><system.web>    <httpModules>        <add name="SetOutputCacheModule" type="MyMVC.SetOutputCacheModule, MyMVC"/>    </httpModules></system.web><!--适用于IIS7的配置（集成模式）--><system.webServer>    <modules>        <add name="SetOutputCacheModule" type="MyMVC.SetOutputCacheModule, MyMVC" preCondition="integratedMode" />    </modules></system.webServer>

配置只是告诉ASP.NET：这些HttpModule需要运行起来。有没有想过这些HttpModule到底是如何进入管线运行起来的呢？前面我只是说了HttpModule会订阅这些事件，那么事件又是在哪里订阅的呢？还是来看一下IHttpModule接口的定义吧：

// 这个接口用于同步调用// 异步用法请参考：http://www.cnblogs.com/fish-li/archive/2011/11/20/2256385.htmlpublic interface IHttpModule{    //  初始化模块，并使其为处理请求做好准备。    void Init(HttpApplication app);    void Dispose();}

注意这个关键的Init方法，它传入一个HttpApplication类型的参数，有了HttpApplication对象，HttpModule就可以订阅HttpApplication的所有事件了。请看下面的示例代码：

public class TestModule : IHttpModule{    public void Dispose() {}    public void Init(HttpApplication app)    {        app.PostAcquireRequestState += new EventHandler(app_PostAcquireRequestState);        app.PreRequestHandlerExecute += new EventHandler(app_PreRequestHandlerExecute);    }    void app_PreRequestHandlerExecute(object sender, EventArgs e)    {        throw new NotImplementedException();    }    void app_PostAcquireRequestState(object sender, EventArgs e)    {        throw new NotImplementedException();    }}

HttpModule的典型应用

public class SetOutputCacheModule : IHttpModule{    public void Init(HttpApplication app)    {        app.PreRequestHandlerExecute += new EventHandler(app_PreRequestHandlerExecute);    }    void app_PreRequestHandlerExecute(object sender, EventArgs e)    {        HttpApplication app = (HttpApplication)sender;        Dictionary<string, OutputCacheSetting> settings = ConfigManager.Settings;        if( settings == null )            throw new ConfigurationErrorsException("SetOutputCacheModule加载配置文件失败。");        // 实现方法：        // 查找配置参数，如果找到匹配的请求，就设置OutputCache        OutputCacheSetting setting = null;        if( settings.TryGetValue(app.Request.FilePath, out setting) ) {            setting.SetResponseCache(app.Context);        }    }

这个Module用于给一些在配置文件中指出要缓存的请求设置输出缓存，示例代码已在上篇博客 不修改代码就能优化ASP.NET网站性能的一些方法 介绍过了。其实设置输出缓存的最根本手段还是调用Response.Cache的一些公开方法，修改输出响应头。

我们用HttpModule做什么事情？

1.  修改某些请求（例如前面的示例修改了响应头）。
2.  检查检查请求（例如身份认证检查）。

HttpModule能处理哪些请求呢？

1.  默认是全部进入ASP.NET的请求。
2.  如果只需要处理部分请求，那么请自行判断（参考前面的示例）。

回到顶部

三大对象的总结

前面我分别介绍了HttpApplication，HttpHanlder和HttpModule，这里再把三者的关系重新梳理一遍。

在请求的处理过程中，HttpApplication对象主要扮演着控制管线处理流程的作用，它负责推进整个处理流程，除了在不同阶段引发不同的事件外（供HttpModule使用），HttpApplication对象还会根据当前请求寻找一个合适的IHttpApplicationFactory实例，并最终得到一个IHttpHandler的实例用于处理请求。

设计这三种类型的目的在于：
1. HttpApplication控制处理流程，在不同阶段引发不同的事件。
2. 由于请求的多样性，每个请求会由一个HttpHandler对象来处理。
3. 对于一些通用性的功能，尤其是与响应内容无关的，设计成HttpModule是最合适的。

回到顶部

案例演示

Q：我有一些html文件，需要做身份认证检查（判断Session），我该如何实现？

想好了就来看看我的解决方案：

/// <summary>/// 用于响应HTML文件的处理器/// </summary>public class HtmlHttpHandler : IHttpHandler, IRequiresSessionState, IReadOnlySessionState {    public void ProcessRequest(HttpContext context)    {        // 获取要请求的文件名        string filePath = context.Server.MapPath(context.Request.FilePath);        // 用Fiddler查看响应头，如果看到有这个头，就表示是由这段代码处理的。        context.Response.AddHeader("SeesionExist", (context.Session != null ? "yes": "no"));        // 在这里，你可以访问context.Session        // 设置响应内容标头        context.Response.ContentType = "text/html";        // 输出文件内容        context.Response.TransmitFile(filePath);    }

在这个案例中我为什么要选择HttpHandler呢？
1. 我需要 响应一类请求（所有的HTML文件）。
2. 请求要求支持 Session
所以我最终选择了HttpHandler 。

Q：我需要压缩所有的ASP.NET请求的响应结果，该怎么实现？

想好了就来看看我的解决方案：

/// <summary>/// 为请求支持gzip压缩输出的DEMO/// </summary>public class GzipModule : IHttpModule{    public void Init(HttpApplication app)    {        app.BeginRequest += new EventHandler(app_BeginRequest);    }    void app_BeginRequest(object sender, EventArgs e)    {        HttpApplication app = (HttpApplication)sender;        // 判断浏览器是否支持GZIP压缩        string flag = app.Request.Headers["Accept-Encoding"];        if( string.IsNullOrEmpty(flag) == false && flag.ToLower().IndexOf("gzip") >= 0 ) {            // 设置GZIP压缩            app.Response.Filter = new GZipStream(app.Response.Filter, CompressionMode.Compress);            app.Response.AppendHeader("Content-Encoding", "gzip");        }    }

在这个案例中我为什么要选择HttpModule呢？
原因只有一个：我需要 设置所有请求。
所以我最终选择了HttpModule 。

回到顶部

如何选择？

在结束这篇博客之前，再问问各位读者：现在知道何时选择HttpHandler还是HttpModule了吗？

如果还没有看明白，那我就最后告诉你一个识别方法：
1. 如果要响应一类请求，那么就选择HttpHandler。
2. 如果要修改或者检查所有请求（总之就是不生成响应结果），那就选择HttpModule。

最后给各位留下一个题目，下面这些ASP.NET提供的功能，它们是采用了哪个方式实现的？
1. Session
2. 身份认证
3. URL授权检查
3. 通过trace.axd查看跟踪信息
4. OutputCache
5. 禁止下载config文件
6. 禁止查看下载源代码文件

注意：本文的主题是：选择HttpHandler还是HttpModule，所以请不要扯远了。

2013年第一篇博客，希望所有读者：万事如意，身体健康！

如果，您认为阅读这篇博客让您有些收获，不妨点击一下右下角的【推荐】按钮。
如果，您希望更容易地发现我的新博客，不妨点击一下右下角的【关注 Fish Li】。
因为，我的写作热情也离不开您的肯定支持。

感谢您的阅读，如果您对我的博客所讲述的内容有兴趣，请继续关注我的后续博客，我是Fish Li 。