Asp.net 深度

最新推荐文章于 2024-07-24 22:04:52 发布

Potter_shen

最新推荐文章于 2024-07-24 22:04:52 发布

阅读量1.3k

点赞数

文章标签： asp.net httpmodule application object webform session

本文链接：https://blog.csdn.net/Potter_shen/article/details/1919052

版权

现在我们可以整理一下完整的一个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 Request并且做些自己的处理，该如何做呢？通过仔细的对上面图示的观察，读者应当知道能够在什么地方截获到这个HTTP请求。对，就是在HTTPRuntime运行时内部来做到这一点的，确切的说，是在HttpModule这个容器中做到这一点的。既然已经进入了神奇的HttpRuntime内部世界，我们当然要多看几眼了，接下来我们会继续我们的历险步伐，向HttpModule容器进军！

我们已经知道HttpModule容器是一个HTTP请求的必经之路，而我们在此小节的任务就是在HttpModule的内部深入看个究竟。

HttpModule在ASP.NET Framework中的位置

我们上回说到，一个来自于客户端的HTTP请求被截获后经过层层转交（怎么都在踢皮球？呵呵）到达了HttpModule这个“请求监听器”。HttpModule就类似于安插在ASPNET_WP.EXE

进程中的一个窃听器，稍微有些常识的人都会很自然的想象得到窃听器是用来做什么的，而我们的HttpModule可以说是作窃听器的绝好人选了，但是需要明确的是，HttpModule绝对不是简单的监听器，它可以做到更多的东西，比如它可以对截获的请求增加一些内容等等。那么HttpModule在整个ASP.NET Framework中的位置处在哪里呢？下面我们通过图示来看看：

另外需要明白的是，当一个HTTP请求到达HttpModule的时候，整个ASP.NET Framework系统还并没有对这个HTTP请求做任何的真正处理，也就是说此时对于HTTP请求来讲，HttpModule只是它路过的一个地方而以。但是正是因为HttpModule是一个HTTP请求的“必经之路”，所以我们可以在这个HTTP请求传递到真正的请求处理中心（HttpHandler）之前附加一些我们需要的信息在这个HTTP请求信息之上，或者针对我们截获的这个HTTP请求信息作一些额外的工作，或者在某些情况下干脆终止满足一些条件的HTTP请求，从而可以起到一个Filter过滤器的作用，而不仅仅是一个窃听器了。通过查阅MSDN（不要去相信.NET SDK自带的那个QuickStarts Web文档，正式版本中竟然在很多地方没有更新这个文档，很多东西在正式版本是无效的），你会发现系统HttpModule实现了一个叫做IHttpModule的接口，很自然的就应当想到，只要我们自己的类能够实现IHttpModule接口，不就可以完全替代系统的HttpModule了吗？完全正确。

在我们开始自己的HttpModule类之前，我先来告诉你系统中的那个HttpModule是什么样子的，ASP.NET系统中默认的HttpModule有以下几个：

System.Web.Caching.OutputCacheModule

System.Web.SessionState.SessionStateModule

System.Web.Security.WindowsAuthenticationModule

System.Web.Security.FormsAuthenticationModule

System.Web.Security.PassportAuthenticationModule

System.Web.Security.UrlAuthorizationModule

System.Web.Security.FileAuthorizationModule

这些系统默认的HttpModule是在文件machine.config中配置，这个文件位于你安装的.NET框架所在的目录中，比如在你的系统文件目录中的C:/WINNT/Microsoft.NET/Framework/v1.0.3705/CONFIG/machine.config。在我们开发ASP.NET 应用程序的时候会频繁的使用到一个web.config配置文件，那么这个machine.config和我们常见的web.config有什么关系呢？原来在ASP.NET Framework启动处理一个Http Request的时候，她会依次加载machine.config以及你请求页面所在目录的web.config文件，里面的配置是有<remove>标签的，什么意思不说也知道了吧。如果你在machine.config中配置了一个自己的HttpModule，你仍然可以在离你最近web.config文件中“remove”掉这个映射关系。

构建我们自己的HttpModule

在上一小节中，我们谈到了系统默认的各个HttpModule均继承实现了一个叫做IhttpModule的接口。我们先来看看这个接口的真实面目吧：

语法：

public interface IHttpModule

需求：

名称空间: System.Web

平台: Windows 2000, Windows XP Professional, Windows .NET Server family

装配件: System.Web (in System.Web.dll)

公共成员方法：

void Dispose();

参数：无

返回值：void

作用：销毁不再被module所使用的资源。

void Init(HttpApplication context);

参数：HttpApplication类型的实例

返回值：void

作用：初始化一个module，为捕获HTTP请求做出一些准备。

了解了接口IhttpModule的方法，我们也就知道了如何去实现它了。

接下来，我们来开始我们自己的HttpModule构建历程吧。

1)打开VS.NET新建一个“Class Library”项目，将它命名为MyHttpModule。

2)引用System.Web.dll文件

在代码区域敲入：

using System;

using System.Web;

namespace MyHttpModuleTest

{

/// <summary>

/// 说明：用来实现自定义HttpModule的类

/// 作者：uestc95

/// 联系：uestc95@263.net

/// </summary>

public class MyHttpModule:IhttpModule

{

/// <summary>

/// 说明：构造器方法

/// 作者：uestc95

/// 联系：uestc95@263.net

/// </summary>

public MyHttpModule()

{

}

/// <summary>

/// 说明：实现IHttpModule接口的Init方法

///作者：uestc95

///联系：uestc95@263.net

/// </summary>

/// <param name="application">HttpApplication类型的参数</param>

public void Init(HttpApplication application)

{

application.BeginRequest +=new EventHandler(this.Application_BeginRequest);

application.EndRequest +=new EventHandler(this.Application_EndRequest);

}

/// <summary>

/// 说明：自己定义的用来做点事情的私有方法

/// 作者：uestc95

/// 联系：uestc95@263.net

/// </summary>

/// <param name="obj">传递进来的对象参数</param>

/// <param name="e">事件参数</param>

private void Application_BeginRequest(Object obj,EventArgs e)

{

//声明HttpApplication

HttpApplication application=(HttpApplication)obj;

HttpContext context=application.Context;

HttpResponse response=context.Response;

HttpRequest request=context.Request;

response.Write("我来自Application_BeginRequest,:)");

}

/// <summary>

/// 说明：自己定义的用来做点事情的私有方法

/// 作者：uestc95

/// 联系：uestc95@263.net

/// </summary>

/// <param name="obj">传递进来的对象参数</param>

/// <param name="e">事件参数</param>

private void Application_EndRequest(Object obj,EventArgs e)

{

HttpApplication application=(HttpApplication)obj;

HttpContext context=application.Context;

HttpResponse response=context.Response;

HttpRequest request=context.Request;

response.Write("我来自Application_EndRequest,:)"）;

}

/// <summary>

/// 说明：实现IHttpModule接口的Dispose方法

/// 作者：uestc95

///联系：uestc95@263.net

/// </summary>

public void Dispose(){}

}

3）在VS.NET中编译之后，你会得到MyHttpModule.dll这个文件。

4）接下来我们的工作就是如何让ASPNET_WP.exe进程将http request交给我们自己写的这个HttpModule呢？方法就是配置web.config文件。

在web.config文件中增加如下几句话：

</httpModules>

注意要区分大小写，因为web.config作为一个XML文件是大小写敏感的。“type=MyHttpModuleTest.MyHttpModule,MyHttpModule”告诉我们，系统将会将HTTP请求交给位于MyHttpModule.dll文件中的MyHttpModuleTest.MyHttpModule类去处理。而这个DLL文件系统将会自动到/bin子目录或者系统全局程序集缓冲区（GAC）搜寻。我们可以将我们刚才得到的DLL文件放在bin子目录中，至于后者，你可以通过.NET SDK正式版自带的Config工具做到，我们不详细说了。

好了，我们的用来截获HTTP请求的自定义HttpModule就完成并且装配完成了，你可以试着在你的web项目中建立一个新的WebForm，运行看看呢？：）

最后，我们假设一个使用这个HttpModule的场合。A站点提供免费的ASP.NET虚拟空间给大家，但是A站点的管理者并不想提供免费的午餐，他想要在每一个页面被浏览的时候自动弹出自己公司的广告，我总不能时刻监视所有用户的所有页面吧，并且想要在每一个页面手动添加一段JS代码，工作量之大是不可想象的，也是非常不现实的。那么好了，只要我们的HttpModule一旦被挂接完成，这一切都将是轻而易举的事情了，只要我们在每一个HTTP请求被我们捕获的时候，给他在HTTP请求信息上面附加上一些我们自己的写的JavaScript代码就好了！

我们上面提到在Init()方法中使用了两个事件BeginRequest和EndRequest，这两个事件分别是Init()中可以处理的所有事件的最开始事件和最终事件，在他们中间还有一些其它的事件可以被我们利用，可以查阅MSDN，这一点我们会在下面详细的讲解。

在下一节开始之前，我们请各位读者考虑这样一个问题：在HttpModule中可以正常使用Response,Request,Server,Application对象吗？请读者自行试着写一些代码看看行不行。还有一个问题就是，在HttpModule中能操作Session对象吗？如果可以或者不可以，请仔细思考一下原因何在，在下一节我们会详细的探讨这个问题。

在这一小节中，我们会详细的探讨有关HttpModule的运行机制，从而使得各位读者能够透彻的了解HttpModule是如何控制HTTP请求的。

我们在上一节曾经提及当一个HTTP请求被ASP.NET Framework捕获之后会依次交给HttpModule以及HttpHandler来处理，但是需要明确的是，不能理解为HttpModule和HttpHandler是完全独立的。实际上是，在HTTP请求在HttpModule传递的过程中会在某个事件内将控制权交给HttpHandler的，而真正的处理在HttpHandler中执行完成之后，HttpHandler会再次将控制权交还给HttpModule。也就是说HttpModule在某个请求经过她的时候会在恰当时候同HttpHandler进行通信，在何时，如何通信呢？这就是下面提到的了。

我们在上一小节提到在HttpModule容器中最开始的事件是BeginRequest，最终的事件是EndRequest。你如果仔细看上次给出的源程序的话，应当发现在方法Init()中参数我们传递的是一个HttpApplication类型，而我们曾经提及的两个事件正是这个传递进来的HttpApplication的事件之一。

HttpApplication还有其它众多的事件，分别如下：

application.BeginRequest事件

application.EndRequest事件

application.PreRequestHandlerExecute事件

application.PostRequestHandlerExecute 事件

application.ReleaseRequestState事件

application.AcquireRequestState事件

application.AuthenticateRequest事件

application.AuthorizeRequest事件

application.ResolveRequestCache事件

application.UpdateRequestCache事件

application.PreSendRequestHeaders事件

application.PreSendRequestContent事件

接下来我们来看看这些事件的含义解释：

HttpApplication事件名称什么时间触发

BeginRequest事件处理HTTP请求开始之前触发

AuthenticateRequest事件验证客户端时候触发

AuthenticateRequest事件执行存取的时候触发

ResolveRequestCache事件从缓存中得到相应时候触发

AcquireRequestState事件加载初始化Session时候触发

PreRequestHandlerExecute事件在HTTP请求送入HttpHandler之前触发

PostRequestHandlerExecute事件在HTTP请求送入HttpHandler之后触发

ReleaseRequestState事件存储Session状态时候触发

UpdateRequestCache事件更新缓存信息的时候触发

EndRequest事件在HTTP请求处理完成时候触发

PreSendRequestHeaders事件在向客户端发送Header之前触发

PreSendRequestContent事件在向客户端发送内容之前触发

需要注意的是，在事件EndRequest之后还会继续执行application.PreSendRequestHeaders事件以及application.PreSendRequestContent事件，而这两个事件大家想必应当从名称上面看得出来事做什么用途的了吧。是的，一旦触发了这两个事件，就表明整个对一个HTTP请求的处理已经执行完成了，在这两个事件中是开始向客户端传送处理完成的数据流了。细心的读者看到这里，会有一个疑问：怎么没见到进入HttpHandler容器就处理完成了？不是提到过HttpHandler容器才是真正处理HTTP请求的吗？

其实一开始我们就提到了，在一个HTTP请求在HttpModule容器的传递过程中，会在某一个时刻（确切的说应当是事件）中将这个HTTP请求传递给HttpHandler容器的。这个事件就是ResolveRequestCache，在这个事件之后，HttpModule容器会建立一个HttpHandler的入口实例（做好准备了，:）），但是此时并没有将HTTP请求的控制权交出，而是继续触发AcquireRequestState事件以及PreRequestHandlerExecute事件（如果你实现了的话）。看到了吗，最后一个事件的前缀是Pre，这表明下一步就要进入HttpHandler容器了，事实上的确如此，正如我们猜想的那样，在PreRequestHandlerExecute事件之后，HttpModule容器就会将控制权暂时交给HttpHandler容器，以便进行真正的HTTP请求处理工作。

而在HttpHandler容器内部会执行ProcessRequest方法来处理HTTP请求。在容器HttpHandler处理完毕整个HTTP请求之后，会将控制权交还给HttpModule，HttpModule则会继续对处理完毕的HTTP请求信息流（此时的HTTP请求信息流已经是被处理过后了的信息流了）进行层层的转交动作，直到返回到客户端为止。

怎么样，是不是有些混乱？下面是一个完整的HttpModule的生命周期示意步骤：

Http Request开始

↓

HttpModule

↓

HttpModule.BeginRequest()

↓

HttpModule.AuthenticateRequest()

↓

HttpModule.AuthorizeRequest()

↓

HttpModule.ResolveRequestCache()

↓

建立HttpHandler控制点

↓

接着处理（HttpHandler已经建立,此后Session可用）

↓

HttpModule.AcquireRequestState()

↓

HttpModule.PreRequestHandlerExecute()

↓

进入HttpHandler处理HttpRequest

↓

HttpHandler.ProcessRequest()

↓

返回到HttpModule接着处理（HttpHandler生命周期结束，Session失效）

↓

HttpModule.PostRequestHandlerExecute()

↓

HttpModule.ReleaseRequestState()

↓

HttpModule.UpdateRequestCache()

↓

HttpModule.EndRequest()

↓

HttpModule.PreSendRequestHeaders()

↓

HttpModule.PreSendRequestContent()

↓

将处理后的数据返回客户端

↓

整个Http Request处理结束

为了更加形象的描述整个HttpModule的HTTP请求处理周期，接下来我们来看看

HTTP请求在整个HttpModule中的生命周期图：

想必读者应当可以从上面的HttpModule生命周期图中找到了上一小节我们提出的那个问题：Session对象在何种情况下可以正常的使用！为了验证上面的流程，我们可以用下面的这个自己的HttpModuel来验证一下就知道了。

注意我们下面给出的是类的内容，代码框架还是上一小节我们给出的那个，自己加上就好了：

public void Init(HttpApplication application)

{

application.BeginRequest += (new EventHandler(this.Application_BeginRequest));

application.EndRequest += (new EventHandler(this.Application_EndRequest));

application.PreRequestHandlerExecute +=(new EventHandler(this.Application_PreRequestHandlerExecute));

application.PostRequestHandlerExecute +=(new EventHandler(this.Application_PostRequestHandlerExecute));

application.ReleaseRequestState +=(new EventHandler(this.Application_ReleaseRequestState));

application.AcquireRequestState +=(new EventHandler(this.Application_AcquireRequestState));

application.AuthenticateRequest +=(new EventHandler(this.Application_AuthenticateRequest));

application.AuthorizeRequest +=(new EventHandler(this.Application_AuthorizeRequest));

application.ResolveRequestCache +=(new EventHandler(this.Application_ResolveRequestCache));

application.PreSendRequestHeaders +=(new EventHandler(this.Application_PreSendRequestHeaders));

application.PreSendRequestContent +=(new EventHandler(this.Application_PreSendRequestContent));

}

private void Application_PreRequestHandlerExecute(Object source, EventArgs e)

{

HttpApplication application = (HttpApplication)source;

HttpContext context = application.Context;

context.Response.Write("Application_PreRequestHandlerExecute<br>");

}

private void Application_BeginRequest(Object source, EventArgs e)

{

HttpApplication application = (HttpApplication)source;

HttpContext context = application.Context;

context.Response.Write("Application_BeginRequest<br>");

}

private void Application_EndRequest(Object source, EventArgs e)

{

HttpApplication application = (HttpApplication)source;

HttpContext context = application.Context;

context.Response.Write("Application_EndRequest<br>");

}

private void Application_PostRequestHandlerExecute(Object source,EventArgs e)

{

HttpApplication application = (HttpApplication)source;

HttpContext context = application.Context;

context.Response.Write("Application_PostRequestHandlerExecute<br>");

}

private void Application_ReleaseRequestState(Object source, EventArgs e)

{

HttpApplication application = (HttpApplication)source;

HttpContext context = application.Context;

context.Response.Write("Application_ReleaseRequestState<br>");

}

private void Application_UpdateRequestCache(Object source, EventArgs e)

{

HttpApplication application = (HttpApplication)source;

HttpContext context = application.Context;

context.Response.Write("Application_UpdateRequestCache<br>");

}

private void Application_AuthenticateRequest(Object source, EventArgs e)

{

HttpApplication application = (HttpApplication)source;

HttpContext context = application.Context;

context.Response.Write("Application_AuthenticateRequest<br>");

}

private void Application_AuthorizeRequest(Object source, EventArgs e)

{

HttpApplication application = (HttpApplication)source;

HttpContext context = application.Context;

context.Response.Write("Application_AuthorizeRequest<br>");

}

private void Application_ResolveRequestCache(Object source, EventArgs e)

{

HttpApplication application = (HttpApplication)source;

HttpContext context = application.Context;

context.Response.Write("Application_ResolveRequestCache<br>");

}

private void Application_AcquireRequestState(Object source, EventArgs e)

{

HttpApplication application = (HttpApplication)source;

HttpContext context = application.Context;

context.Response.Write("Application_AcquireRequestState<br>");

}

private void Application_PreSendRequestHeaders(Object source, EventArgs e)

{

HttpApplication application = (HttpApplication)source;

HttpContext context = application.Context;

context.Response.Write("Application_PreSendRequestHeaders<br>");

}

private void Application_PreSendRequestContent(Object source, EventArgs e)

{

HttpApplication application = (HttpApplication)source;

HttpContext context = application.Context;

context.Response.Write("Application_PreSendRequestContent<br>");

}

public void Dispose()

{

}

将上面的代码编译成为一个类库文件，再按照上一小节给出的方法将它挂接到ASP.NET Framework系统,你运行此演示代码就可以看到和我们给出的HttpModule生命周期图是完全吻合的。

现在我们来思考这样一个问题：如果我同时编写了多个自定义的HttpModule，并且也都装配了他们，ASP.NET Framework会怎样加载这多个自定义的HttpModule呢？下面我们就一同通过一个完整的例子来演示看看：我们在下面的代码中会建立两个HttpModule类库DLL文件，并且同时装配他们在web.config中。

1）、在VS.NET中建立一个名为IhttpModule的类库项目

2）、引入名称空间文件System.Web.dll

3）、在代码区域输入如下的代码：

using System;

using System.Web;

using System.Collections;

public class HelloWorldModule : IHttpModule

{

public String ModuleName

{

get { return "HelloWorldModule"; }