了解當用戶對一個.aspx頁面提出請求時，后臺的Web服務器的動作流程。當對這個流程了解后，我們就會明白HttpHandler和HttpModule的作用了。

首先，來了解一下IIS系統。它是一個程序，負責對網站的內容進行管理，以及對客戶的請求（就是Http請求）做出反應。當用戶對一個頁面提出請求時，IIS做如下反應（忽略權限）：
1.把對方請求的虛擬路徑轉換成物理路徑
2.根據物理路徑搜索請求的文件
3.找到文件后，獲取文件的內容
4.生成Http頭信息。
? PS：關于IIS和IE生成的Http頭信息（元數據），可以用這個工具：http://www.blunck.info/iehttpheaders.html，它是IE的一個插件，專門查看頭信息的。
5.向客戶端發送所有的文件內容：首先是頭信息，然后是Html內容，最后是其它文件的內容。
6.客戶端IE瀏覽器獲得信息后，解析文件內容，找出其中的引用文件，如.js .css .gif等，向IIS請求這些文件。
7.IIS獲取請求后，發送文件內容。
8.當瀏覽器獲取所有內容后，生成內容界面，客戶就看到圖像/文本/其它內容了。

但是IIS有個缺點，即它僅僅支持靜態html頁面的內容，就是說，他只能分析如.htm，.html這樣的文件內容。像一些動態內容的頁面，含有服務器端操作代碼的頁面類型，如.asp，.aspx，.cgi，.php等，IIS不認識這些專用的標記，它就會把它當作文本，絲毫不做處理發送到客戶端。

為了解決這個問題。IIS推出了一種機制，叫做ISAPI的開放擴展，這個東西是一個標準組件(COM組件),他是一個過濾器+跳轉程序，如果安裝了專門的擴展，那么在訪問IIS所不能處理的文件時，如.asp和.aspx文件，IIS就會在自己的進程里面啟動這個擴展。剛才說了，ISAPI首先是個過濾器，他在注冊到IIS的時候，會把每個擴展可以處理的文件擴展名注冊到IIS里面。擴展啟動后，就根據定義好的方式來處理IIS所不能處理的文件，然后把控制權跳轉到專門處理代碼的進程中。讓這個進程開始處理代碼，生成標準的HTML代碼，生成后把這些代碼加入到原有的Html中，最后把完整的Html返回給IIS，IIS再把內容發送到客戶端。

我拿一個請求asp.net頁面的執行步驟說明：
1 客戶端IE瀏覽器通過Http協議向一個Web服務器提出請求，如
? http://www.microsoft.com/china/msdn/default.mspx

2 當請求到達時，IIS 檢查資源類型（就是檢查請求文件的擴展名，發現不是自己所能處理的），就調用 ASP.NET ISAPI 擴展。如果啟用了默認的進程模型，aspnet_isapi 會將請求排隊，并將請求分配給輔助進程。所有的請求數據都通過異步 I/O 發送。如果啟用了 IIS 6 進程模型，請求將自動在輔助進程 (w3wp.exe) 中排隊，此輔助進程用于處理應用程序所屬的 IIS 應用程序池。IIS 6 輔助進程不了解 ASP.NET 和托管代碼的任何情況，它只是處理 *.aspx 擴展并加載 aspnet_isapi 模塊。當 ASP.NET ISAPI 在 IIS 6 進程模型中運行時，它的工作方式有所不同，僅在 w3wp.exe 輔助進程的上下文中加載 CLR。

3 收到請求后，ASP.NET 輔助進程將通知 ASP.NET ISAPI，它將為請求服務。通知通過同步 I/O 實現。之所以使用同步模型，是因為請求只有在 ISAPI 內部請求表中被標記為“executing”，輔助進程才能開始處理它。如果請求已經由特殊的輔助進程進行處理，則不能再將它指定到其他進程，除非原始進程已取消。

4 完成后，響應被發送到打開了異步管道的 aspnet_isapi。現在，請求的狀態變為“Done”，之后將從請求表中被刪除。如果輔助進程崩潰，正在處理的所有請求仍將保持“executing”狀態并持續一段時間。如果 aspnet_isapi 檢測到輔助進程已取消，它將自動終止請求并釋放所有相關的 IIS 資源。

5 最后，ISAPI獲取了響應（就是經過asp.net運行庫所處理后的html內容）后，把響應返回給IIS，IIS將繼續處理它的內容，解析所需相關文件，并且把所有的數據發送給客戶端。然后關閉連接。

從上面的敘述可以知道，最終要的步驟是Asp.net處理的那一段過程，就是當asp.net的ISAPI啟動處理進程后發生了什么事

?

總結

以上是生活随笔為你收集整理的HttpHand和HttpModule的详细解释，包括Asp.Net对Http请求的处理流程。的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。