HTTP handlers和Module簡介

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。

本文轉自cnn23711151CTO部落格，原文連結：http://blog.51cto.com/cnn237111/591806 ，如需轉載請自行聯系原作者