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服务器扩展。
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。
本文转自cnn23711151CTO博客，原文链接：http://blog.51cto.com/cnn237111/591806 ，如需转载请自行联系原作者
