HTTP handlers和Module是ASP.NET平台的基本模块。任何对ASP.NET资源的请求总是通过HTTP Module管道并且由HTTP Handler处理。
Page类,是最终的HTTP handler,它在内部实现了页面的生命周期。包括postback,Init,Load,PreRender之类的。一个HTTP handler设计为处理一个或者更多的URL扩展。Handler可以被赋予应用程序或者机器范围。
HTTP Module是处理运行时事件的类,Module可以处理有两种类型的事件,这些事件由HttpApplication(包括异步事件)和其他HTTP module提供。比如SessionStateModule就是一个ASP.NET内建的Module,它用来提供Session状态服务,它触发了End和Start事件,其他Module可以通过熟悉的Session_End和Session_Start签名处理。
IIS7集成模式,module和handler在IIS级别处理。
HTTP modules and handlers 都和请求路由主题相关。起初是为了ASP.NET MVC开发的,URL路由引擎在 .NET Framework 3.5 Service Pack 1中被合并到ASP.NET平台中。URL路由引擎是系统提供的HTTP Module,它钩住所有的请求,并试图匹配请求的URL到用户自定义的路由规则。如果匹配,module定位HTTP handler去处理。如果不存在,那么请求会被按照普通的web form 处理,就好像没有URL路由引擎。
一个web服务器通常提供一个应用程序接口API,来提升和自定义服务器的能力。首先出现的扩展API就是 Common Gateway Interface (CGI)。现今,CGI应用程序几乎不再使用,因为他们对每一个请求需要一个新的进程,这个方法不适合高容量的web站点。
更多的现在版本的web服务器提供一个可供选择的更有效率的模型来扩展Server能力。在IIS中,这种模型采用ISAPI接口的形式。当一个ISAPI模型使用时,不是为每个请求启动一个新的进程,Web服务器载入定制的命名的组件—一个win32动态链接库到他自己的进程中。
这种模式的缺点在于,因为组件被装载进Web服务器进程内,一个简单的组件的错误都可以让整个服务器和安装的应用程序崩溃。目前已有一些有效的策略来缓解这种缺点。
今天,IIS安装的应用程序可以指定应用程序池,每个应用程序池都为不同的工作进程的实例服务。ISAPI也不是最优化的模型,因为他需要开发者创建非托管dll来赋予web服务器服务专用请求的能力,比如请求ASPX资源。
直到IIS7(当IIS 7配配置为经典模式时候),请求由IIS处理,然后被映射到某些ISAPI(非托管)组件。对ASPX请求是就是这样的, ASP.NET ISAPI组件是aspnet_isapi.dll。在IIS 7.x集成模式,你可以添加托管组件(HTTP handlers和HTTP modules)在IIS级别上。准确的说,IIS7继承模式融合了ASP.NET内部运行管道和IIS管道,让你能够用托管代码写WEB服务器扩展。
今天,如果你学怎么样写 HTTP handlers 和 HTTP modules,你可以使用这种技巧定制请求怎么被IIS处理,不需要仅仅把请求映射到ASP.NET。