最近开发中涉及到一些使用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重写做了个小测试
{
bool IsReusable { get ; }
void ProcessRequest(HttpContext context);
}
IsReusable获取一个值,该值指示其他请求是否可以使用 System.Web.IHttpHandler 实例。
System.Web.HttpContext 对象,它提供对用于为 HTTP 请求提供服务的内部服务器对象(如 Request、Response、Session 和 Server)的引用。