浅析IHttpModule和IHttpHandler

最近开发中涉及到一些使用IHttpModule和IHttpHandler，储备不够便到MSDN学习了一下。

 

这两个接口是怎么产生的呢，这恐怕要从IIS处理外部请求说起：

IIS本身无法处理动态页面，仅支持静态HTML页面，为了解决此问题引入了ISPAI机制，从字面理解就是一个API，这种机制有两种实现方式

IHttpModule:这个接口被赋予了ISAPI过滤器功能，通过对HttpApplication对象的一系列事件的处理来对Http处理管道施加影响,这些方法在HttpModule的Init事件中注册，通常会在webconfig文件中进行配置，也可以有多个HttpModule，执行顺序在webconfig中注册的顺序是一致的，而且每一个都会执行。但是IHttpHandler却是如果第一个适配后面的就不再重复执行，他的Init方法和Application_Start是不同的，HTTPRuntime维护着一个HttpApplication Pool而他是并发的所以多个用户访问可能会多次执行Init，而Application_Start这个方法只在服务器第一次启动时执行
IHttpHandler:他是实现了ISAPI扩展功能,可以自定义实现IHttpHandler，然后在IIS服务器重注册，进而实现自己喜欢的扩张名，别忘了在config文件中也注册

理解这个之后可以在处理HttpRequest之前就进行校验，而不是传统的挥发到页面在处理，这样的提前处理对海量访问的效率提高有好处 

一，IHttpModule

查看这个接口的代码可以发现，它是由两个方法组成：

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

看到两个方法及方法标签，就明白这个IHttpModule接口有什么作用了，Init方法中传入了一个HttpApplication参数，它提供对 ASP.NET 应用程序内所有应用程序对象的公用的方法、属性和事件的访问，包括了HttpApplication下的方法、属性和事件的访问。那么具体有那些呢？

包括了所有我们经常会用到的一些对象，Application,Context,Event,Modules,Request,Response,Server,Session,Site,User,BeginRequest,EndRequest等等，其中Context中有个一个方法Context.RewritePath可以用来重写URL的，也就是说只要你在App_code中添加一个继承IHttpModule接口的类，并在webconfig中添加此Module后，这个类就可以处理全局的应用程序所有的方法、属性和事件了。

这里针对URL重写做了个小测试

 

public   interface  IHttpHandler

{   

bool  IsReusable {  get ; }      

void  ProcessRequest(HttpContext context);    

}

 

 

 

IsReusable获取一个值，该值指示其他请求是否可以使用 System.Web.IHttpHandler 实例。

System.Web.HttpContext 对象，它提供对用于为 HTTP 请求提供服务的内部服务器对象（如 Request、Response、Session 和 Server）的引用。