关于HttpModule和HttpHandler以及HttpApplication

HttpRuntime打交道的是http协议跟IIS层面的东西,HttpApplication则具体到应用程序这一级别(也就是一个网站,这个跟web.config关系是基本一一对应的,像Module跟Handler的信息都是在这里定义),此时会生成相应的HttpContext(上下文信息,包括Request,Response等),在HttpApplication路由到具体的HttpHandler处理之时,HttpApplication的各个事件会被触发,而HttpModule则通过相应的事件如BeginRequest等来处理一些额外的事情,如UrlRewrite,缓存,安全验证等

管线(Pipeline)这个词也是很有点意思,这个词也形象地说明了每个Asp.net请求的处理过程: 请求是在一个管道中,要经过一系列的过程点,这些过程点连接起来也就形成一条线。 以上是我对于这个词的理解,如果有误,恳请给予指正。 这些一系列的过程点,其实就是由HttpApplication引发的一系列事件,通常可以由HttpModule来订阅, 也可以在Global.asax中订阅,这一系列的事件也就构成了一次请求的生命周期。

观察者模式:观察者模式定义了对象之间的一种联系,使得当一个对象改变状态时,其它对象会被相应的通知到。

Asp.net的管线设计正是采用了这种方式, 在这个设计模式中,观察者就是许多HttpModule对象,被观察的对象就是每一个请求,它的状态由HttpApplication控制,用于描述当前请求的处理阶段,

HttpApplication会根据一个特定的顺序修改这个状态,并在每个状态改变后引发相应的事件。 Asp.net会为每个请求分配一个HttpApplication对象来引发这些事件,因此可以让一大批观察者了解每个请求的状态, 每个观察者也可以在感兴趣的时候修改请求的一些数据。 这些与请求相关的数据的也就是HttpRequest, HttpResponse。

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

对于这些管道事件

1.每个请求都将会映射到一个HttpHandler,通常也是处理请求的主要对象。

2.HttpModule可以任意订阅这些事件,在事件处理器中也可以参与修改请求的操作。

HttpHandler

HttpHandler通常是处理请求的核心对象。绝大多数的的请求都在【第10步】被映射到一个HttpHandler, 然后在【第15步】中执行处理过程,因此也常把这类对象称为处理器或者处理程序。我们熟知的Page就是一个处理器, 一个ashx文件也是一个处理器。

// 定义 ASP.NET 为使用自定义 HTTP 处理程序同步处理 HTTP Web 请求而实现的协定。
public interface IHttpHandler
{
// 获取一个值,该值指示其他请求是否可以使用 System.Web.IHttpHandler 实例。
//
// 返回结果:
// 如果 System.Web.IHttpHandler 实例可再次使用,则为 true;否则为 false。
bool IsReusable { get; } // 通过实现 System.Web.IHttpHandler 接口的自定义 HttpHandler 启用 HTTP Web 请求的处理。
void ProcessRequest(HttpContext context);
}

我们可以采用以下方式在web.config中注册一个自定义的处理器:

<httpHandlers>
<add path="/MyService.axd" verb="*" validate="false" type="MySimpleServiceFramework.MyServiceHandler"/>
</httpHandlers>

HttpModule

前面我已经提到过HttpModule的工作方式:订阅管线事件,并在事件处理器中执行所需的相关操作。
这个描述看起来很平淡,但是,它的工作方式给了它无限强大的处理能力。

它的无限强大的处理能力来源于可以订阅管线事件,因此,它有能力可以在许多阶段修改请求, 这些修改最终可能会影响请求的处理。
前面我说过:“HttpHandler是处理请求的主要对象”,但HttpModule却可以随意指定将某个请求交给某个处理器来执行!
甚至,HttpModule也可以直接处理请求,完全不给HttpHandler工作的机会!

public interface IHttpModule
{
void Dispose(); void Init(HttpApplication app);
}

在这二个方法中,第一个方法通常可以保持为空。最重要的方法就是Init,它给了HttpModule能订阅管线事件的机会, 然后在相应的事件处理中,我们就可以执行它的具体操作了。

<httpModules>
<add name="DuplexGzipModule" type="MySimpleServiceFramework.DuplexGzipModule"/>
</httpModules>

HttpModule的加载方式:ASP.NET会为每个请求分配一个HttpApplication对象,在每个HttpApplication对象的初始化操作中,它会加载所有在web.config中注册的HttpModule。由于Asp.net并不是只创建一个HttpApplication对象,而是多个HttpApplication对象, 因此每个HttpModule的Init事件是有可能被多次调用的。

上一篇:.NET Core开发者的福音之玩转Redis的又一傻瓜式神器推荐


下一篇:Codeforces Round #523 (Div. 2) C. Multiplicity