ASP.NET頁面與IIS底層交互和工作原理詳解 - lumnm - 博客園

06-04

ASP.NET頁面與IIS底層交互和工作原理詳解

第一回：引言

我查閱過不少Asp.Net的書籍，發現大多數作者都是站在一個比較高的層次上講解Asp.Net。他們耐心、細緻地告訴你如何一步步拖放控制項、設置控制項屬性、編寫CodeBehind代碼，以實現某個特定的功能。

這種做法，實際上是回答了「如何去做」的問題，卻沒有回答「為什麼可以這樣做」的問題。

儘管我很推崇悉江華先生的《聖殿祭祀的Asp.Net開發詳解》一書，但當我翻看了一下其對角色(Role) 和用戶(Member)的講解時，我決定跳過去直接讀後面的章節。因為我發現他也隨了大流，對這部分的講解停留在「如何去做」的層面上。我相信像悉先生這樣的牛人是不可能不了解底層運作原理的，僅僅是因為那本書原本就已經很厚了吧。

當你按「如何去做」所講解的內容去開發程序的時候，對於你的用戶，你仍是一名程序員；但對於實現了MembershipProvider 和 RoleProvider 抽象類的微軟開發人員來說，你已經成了他們的一個用戶。

NOTE：我既不反對一些作者只講解「如何去做」，也不反對你只學「如何去做」，這樣也有它的好處，就是可以快速開發。我只是建議多掌握一點底層知識，對一些問題會有更好的理解。

希望通過這一系列文章的講解，可以讓你更好的理解Asp.Net的運作原理和做以了解。

Http請求處理流程概述

思考「為什麼在地址欄輸入www.tracefact.net就可以看到張子陽的個人空間？」，類似於思考「為什麼蘋果是往地上掉不是往天上飄？」。對於普通訪問者來說，這就像每天太陽東邊升起西邊落下一樣是理所當然的；對於很多程序員來說，認為這個與己無關，不過是系統管理員或者網管員的責任。畢竟，IIS是 Windows 的一個組件，又不是 Asp.Net 的一個組成部分。而實際上，從你輕拍回車到頁面呈現在你眼前的十分之一秒內，IIS和.Net Framework已經做了大量的幕後工作。

你可能覺得了解這些幕後工作是如何運作的無關緊要，作為程序員的你只要保證開發出的程序可以高效地運行就可以了。然而，在開發過程中，你卻發現常常需要使用諸如 HttpContext 這樣的類。這個時候，你可曾思考過這些類的構成和類的實體是如何創建的？你可能簡單地回答：HttpContext代表當前請求的一個上下文環境。可你又知道IIS 、Framework、Asp.Net 是如何協同工作處理每個Http請求、如何區分不同的請求、IIS、Framework、Asp.Net三者之間的數據如何流動么？

回答上面這些問題，首先需要了解IIS是如何處理頁面請求的，這也是理解 Form驗證模式和Windows 驗證模式的基礎。

Http請求剛剛到達伺服器的時候

當伺服器接收到一個 Http請求的時候，IIS 首先需要決定如何去處理這個請求（NOTE：伺服器處理一個.htm頁面和一個.aspx頁面肯定是不一樣的么）。那IIS依據什麼去處理呢？―― 根據文件的後綴名。

伺服器獲取所請求的頁面（NOTE：也可以是文件，比如 jimmy.jpg）的後綴名以後，接下來會在伺服器端尋找可以處理這類後綴名的應用程序，如果IIS找不到可以處理此類文件的應用程序，並且這個文件也沒有受到伺服器端的保護（NOTE：一個受保護的例子就是 App_Code中的文件，一個不受保護的例子就是你的js腳本），那麼IIS將直接把這個文件返還給客戶端。

能夠處理各種後綴名的應用程序，通常被稱為 ISAPI 應用程序（NOTE：Internet Server Application Programe Interface，互聯網伺服器應用程序介面）。雖然這 ISAPI 聽上去還挺氣派，也算是「應用程序」呢，但仔細看看它的全稱就明白了：它實際上只是一個介面，起到一個代理的作用，它的主要工作是映射所請求的頁面(文件) 和與此後綴名相對應的實際的處理程序。

讓我們更進一步地看一下 ISAPI ，看看它到底是什麼樣子，請按下面的步驟進行：

打開IIS。
選擇隨意一個站點，滑鼠右鍵，「屬性」。
選擇「主目錄」選項卡。
選擇「配置」。

你應該會看到如下的畫面：

圖1. 應用程序配置

很清楚地就可以看到，所有IIS所能處理，或者叫 ISAPI 所提供代理服務的文件類型及其相對應的實際的後台處理程序都在這裡清楚地列出來了。

我們找到 .aspx 的應用處理程序，然後點「編輯」，會出現下面的畫面：

圖2. 編輯.aspx文件的處理程序

一路看到這裡，可以看出，所有的.aspx文件實際上都是由 aspnet_isapi.dll 這個程序來處理的，當IIS把對於.aspx頁面的請求提交給了aspnet_isapi.dll以後，它就不再關心這個請求隨後是如何處理的了。現在我們應該知道：Asp.Net 只是伺服器(IIS)的一個組成部分而已，它是一個 ISAPI擴展。

這裡需要注意兩點：

當你修改「限制為」後，可以限制頁面(文件)只能以某種特定方式訪問

「確認文件是否存在」是實現 URL 地址映射的關鍵選項，我以後會專門講述。

理解宿主環境（Hosting）

從本質上講，Asp.Net 主要是由一系列的類組成，這些類的主要目的就是將Http請求轉變為對客戶端的響應。HttpRuntime類是Asp.Net的一個主要入口，它有一個稱作 ProcessRequest 的方法，這個方法以一個 HttpWorkerRequest 類作為參數。HttpRuntime 類幾乎包含著關於單個 Http請求的所有信息：所請求的文件、伺服器端變數、QueryString、Http 頭信息等等。Asp.Net 使用這些信息來載入、運行正確的文件，並且將這個請求轉換到輸出流中，一般來說，也就是HTML頁面。

NOTE：二般來說，也可以是張圖片。

當 Web.config文件的內容發生改變或者 .aspx文件發生變動的時候，為了能夠卸載運行在同一個進程中的應用程序（NOTE：卸載也是為了重新載入），Http請求被分放在相互隔離的應用程序域中。

NOTE：可能你以前就聽過應用程序域，但是不了解怎麼回事，應用程序域就是 AppDomain。

對於IIS來說，它依賴一個叫做 HTTP.SYS 的內置驅動程序來監聽來自外部的 HTTP請求。在操作系統啟動的時候，IIS首先在HTTP.SYS中註冊自己的虛擬路徑。

NOTE：實際上相當於告訴HTTP.SYS哪些URL是可以訪問的，哪些是不可以訪問的。舉個簡單的例子：為什麼你訪問不存在的文件會出現 404 錯誤呢？就是在這一步確定的。

如果請求的是一個可訪問的URL，HTTP.SYS會將這個請求交給 IIS 工作者進程。

NOTE：IIS6.0中叫做 w3wp.exe，IIS5.0中叫做 aspnet_wp.exe。

每個工作者進程都有一個身份標識以及一系列的可選性能參數。

NOTE：可選性能參數，是指諸如回收機制的設置、超時時間設置等等。

接下來進行的事情就是上一章節講述的 ISAPI 了。

NOTE：這部分的內容相關性比較強，為了讓大家好理解，我最後還是決定把 ISAPI 放到前面了，可能全系列完成的時候會再調整吧。

除了映射文件與其對應的處理程序以外，ISAPI 還需要做一些其他的工作：

從HTTP.SYS中獲取當前的Httq請求信息，並且將這些信息保存到 HttpWorkerRequest 類中。
在相互隔離的應用程序域AppDomain中載入HttpRuntime。
調用 HttpRuntime的ProcessRequest方法。

接下來才是程序員通常編寫的代碼所完成的工作了，然後，IIS 接收返回的數據流，並重新返還給 HTTP.SYS，最後，HTTP.SYS 再將這些數據返回給客戶端瀏覽器。

OK，現在你看到張子陽的空間主頁了。

圖3.Asp.Net 的宿主環境

理解管道（Pipeline）

在前面兩章中，我們在一個相對比較低的層次上討論了從發出Http請求到看到瀏覽器輸出這轉瞬即逝的十分之一秒內IIS和 Framework 所做的事情。但是我們忽略了一個細節：程序員編寫的代碼是如何在這一過程中銜接的，本章我們就來看看這個問題。

當Http請求進入 Asp.Net Runtime以後，它的管道由託管模塊（NOTE：Managed Modules）和處理程序（NOTE：Handlers）組成，並且由管道來處理這個 Http請求。

圖4. 理解 Http 管道

我們按編號來看一下這幅圖中的數據是如何流動的。

1. HttpRuntime將Http請求轉交給 HttpApplication，HttpApplication代表著程序員創建的Web應用程序。HttpApplication創建針對此Http請求的 HttpContext對象，這些對象包含了關於此請求的諸多其他對象，主要是HttpRequest、HttpResponse、HttpSessionState等。這些對象在程序中可以通過Page類或者Context類進行訪問。、

2. 接下來Http請求通過一系列Module，這些Module對Http請求具有完全的控制權。這些Module可以做一些執行某個實際工作前的事情。

3. Http請求經過所有的Module之後，它會被HttpHandler處理。在這一步，執行實際的一些操作，通常也就是.aspx頁面所完成的業務邏輯。可能你會覺得在創建.aspx頁面並沒有體會到這一過程，但是，你一定知道，.aspx 頁面繼承自Page類，我們看一下Page類的簽名：

public class Page : TemplateControl, IHttpHandler{ // 代碼省略}

可以看到，Page類實現了IHttpHandler介面，HttpHandler也是Http請求處理的最底層。

4.HttpHandler處理完以後，Http請求再一次回到Module，此時Module可以做一些某個工作已經完成了之後的事情。

NOTE：注意我用紅色標識的字，然後回想一下：Asp.Net 中是不是有眾多的 Inserting 、Inserted 之類成對的事件？其實，這裡講述的就是為什麼Asp.Net可以將一個Insert操作分成前後兩部分，然後再分別進行事件攔截的幕後原理。

如果我們將注意力只集中在Http請求、HttpHandler和HttpModule上，不去考慮HttpContext和HttpApplication，那麼圖4.可以簡化成下面這樣：

圖5.Http請求在HttpHandler 和 HttpModule 中的流動方向

總結

本文中，我首先概要介紹了這系列文章將要為大家講述的主題。然後，我提出了部分程序員存在的一個問題：在一個比較高的層次上學習和使用Asp.Net。

隨後，我以一個訪問我個人空間首頁的例子，引出了本文主要講述的三個內容：

Http請求剛剛到達時IIS時，IIS 所做的工作。
Http請求的宿主環境。
Http管道。

希望這篇文章能給你帶來幫助。

第二回：引言

在 Part.1 Http請求處理流程一文中，我們了解了Http請求的處理過程以及其它一些運作原理。我們知道Http管道中有兩個可用介面，一個是IHttpHandler，一個是IHttpModule，但在Part.1中，我並沒有詳細講述如何對它們進行編程，只是輕描淡寫地一筆帶過。所謂學以致用，前面已經介紹了不少概念和原理。在本文中，我們通過幾個範例來了解 IHttpHandler，看看掌握這些原理的實際用途。

IHttpHandler 概述

可能和我一樣，很多Asp.Net開發人員都有過Asp的背景，以至於我們在開發程序的時候，通常都是在「頁面級」上思考，也就是說我們現在正在做的這個頁面應該有什麼樣的功能，是進行一個問卷調查還是一個資料庫查詢等等。而很少在「請求級」思考，考慮有沒有辦法來通過編碼的方式來操控一個Http請求。

實際上，Framework提供了一系列的介面和類，允許你對於Http請求進行編程，而實現這一操作的一個主要的介面，就是 IHttpHandler(另一個是IHttpModule)。

應該還記得第一節中我們提到過 ISAPI，它根據文件名後綴把不同的請求轉交給不同的處理程序。但是仔細看看就會發現：幾乎一大半的文件都交給 aspnet_isapi.dll 去處理了。很明顯，aspnet_isapi.dll 不可能對每種文件採用同一種方式處理，那麼 aspnet_isapi.dll 是如何更進一步處理不同的文件，交由誰去處理呢？為了搞清楚這個問題，我們需要打開機器上C:WINDOWSMicrosoft.NETFrameworkv2.0.50727CONFIG 目錄下的web.config 文件。

NOTE：我查閱了很多資料，都說是在 machine.config 中，但實際上 v2.0.50727 下的machine.config中httpHandlers結點是這樣的：<httpHandlers />，並沒有給出詳細的處理程序，在Web.config中才能看到。而v1.1.4322 下的machine.config中卻有。

找到httpHandlers結點，應該可以看到如下這樣的代碼(做了省略)：

可以看到，在<httpHandlers>結點中將不同的文件類型映射給不同的Handler去處理，對於.aspx來說，是由System.Web.UI.PageHandlerFactory來處理。而對於.cs來說，是由System.Web.HttpForbiddenHandler 處理，從ForbiddenHandler名字中出現的Forbidden (翻譯過來是「禁止」)可以看出，這個Handler可以避免我們的源碼被看到。

NOTE：System.Web.UI.PageHandlerFactory 是一個IHttpHandlerFactory，而不是一個單一的HttpHandler，IHttpHandlerFactory用來做什麼後面會說明。

上面列出的是.Net Framework在處理Http請求時的所採用的默認Handler。而如果我們要用編程的方式來操控一個Http請求，我們就需要實現IHttpHandler介面，來定製我們自己的需求。

IHttpHandler的定義是這樣的：

public interface IHttpHandler{ void ProcessRequest(HttpContext context); bool IsReusable { get; }}

由上面可以看出IHttpHandler要求實現一個方法和一個屬性。其中 ProcessRequest，從名字(處理請求)看就知道這裡應該放置我們處理請求的主要代碼。

IsReusable屬性，MSDN上是這樣解釋的：獲取一個值，該值指示其他請求是否可以使用 IHttpHandler 實例。也就是說後繼的Http請求是不是可以繼續使用實現了該介面的類的實例，一般來說，我把它設置成true。

那麼實現此介面的類形式應該是這樣的：

public class CustomHandler : IHttpHandler{ public void ProcessRequest(HttpContext context) { // 處理請求的代碼 } public bool IsReusable { get { return true; } }}

而為了能使用這個自定義的HttpHandler，我們需要在應用程序目錄下的Web.config中註冊它。

<system.web> <httpHandlers> <add path="*.jpg" verb="*" type="MyNameSpace.MyClass, MyDllName" /> </httpHandlers></system.web>

應該發現這與之前在C:WINDOWSMicrosoft.NETFrameworkv2.0.50727CONFIG目錄下web.config中看到的幾乎完全一樣。這裡，path指的是請求的文件名稱，可以使用通配符擴大範圍，也可以明確指定這個handler僅用於處理某個特定的文件(比如說：filename.aspx)的請求。verb指的是請求此文件的方式，可以是post或get，用*代表所有訪問方式。type屬性由「,」分隔成兩部分，第一部分是實現了介面的類名，第二部分是位於Bin目錄下的編譯過的程序集名稱。

NOTE：如果你新建一個項目，並且在項目下創建HandlerTest.cs，然後讓站點引用該項目，那麼在生成解決方案的時候會自動將編譯好的.dll文件添到Bin目錄中。 NOTE：MyDll只寫程序集名，不要加後面的.dll。

使用HttpHandler實現圖片防盜鏈

有了之前這麼多的準備知識，實現現在的目標就容易得多了：

NOTE：這個例子，以及下面的一個例子均來自於《Maximizing ASP.NET Real World, Object-Oriented Development》一書：

Step.1：創建文件 CustomHandler.cs，代碼如下：

using System;using System.Web;namespace CustomHandler{ public class JpgHandler : IHttpHandler{ public void ProcessRequest(HttpContext context){ // 獲取文件伺服器端物理路徑 string FileName = context.Server.MapPath(context.Request.FilePath); // 如果UrlReferrer為空，則顯示一張默認的禁止盜鏈的圖片 if (context.Request.UrlReferrer.Host == null){ context.Response.ContentType = "image/JPEG"; context.Response.WriteFile("/error.jpg"); }else{ // 如果 UrlReferrer中不包含自己站點主機域名，則顯示一張默認的禁止盜鏈的圖片 if (context.Request.UrlReferrer.Host.IndexOf("yourdomain.com") > 0){ context.Response.ContentType = "image/JPEG"; context.Response.WriteFile(FileName); }else{ context.Response.ContentType = "image/JPEG"; context.Response.WriteFile("/error.jpg"); } } } public bool IsReusable{ get{ return true; } } }}

Step.2 編譯這個文件

csc /t:library /r:System.Web.dll CustomHandler.cs

Step.3 將編譯好的 CustomHandler.dll 拷貝到站點的 Bin 目錄下。Step.4 在Web.Config 中註冊這個Handler。

<system.web> <httpHandlers> <add path="*.jpg" verb="*" type="CustomHandler.JpgHandler, CustomHandler" /> </httpHandlers></system.web>

OK，諸位可以按步驟自行測試一下，這裡就不贅述了。

通過IhttpHandler實現圖片驗證碼

也可以在一個.ashx文件中實現IHttpHandler，而不是採用這種提前編譯的方式。

Step.1 打開Vs2005，「添加新項」，「一般處理程序」。新建文件後，VS會自動在文件中添加如下的代碼：

<%@ WebHandler Language="C#" Class="Handler" %>using System;using System.Web;public class Handler : IHttpHandler { public void ProcessRequest (HttpContext context) { context.Response.ContentType = "text/plain"; context.Response.Write("Hello World"); } public bool IsReusable { get { return false; } }}

Step.2 將代碼改寫成如下所示：

<%@ WebHandler Language="C#" Class="Handler" %>using System;using System.Drawing;using System.Drawing.Imaging;using System.Text;using System.Web;using System.Web.SessionState;public class Handler : IHttpHandler, IRequiresSessionState { public void ProcessRequest(HttpContext context) { context.Response.ContentType = "image/gif"; //建立Bitmap對象，繪圖 Bitmap basemap = new Bitmap(200, 60); Graphics graph = Graphics.FromImage(basemap); graph.FillRectangle(new SolidBrush(Color.White), 0, 0, 200, 60); Font font = new Font(FontFamily.GenericSerif, 48, FontStyle.Bold, GraphicsUnit.Pixel); Random r = new Random(); string letters = "ABCDEFGHIJKLMNPQRSTUVWXYZ"; string letter; StringBuilder s = new StringBuilder(); //添加隨機的五個字母 for (int x = 0; x < 5; x++) { letter = letters.Substring(r.Next(0, letters.Length - 1), 1); s.Append(letter); graph.DrawString(letter, font, new SolidBrush(Color.Black), x * 38, r.Next(0, 15)); } //混淆背景 Pen linePen = new Pen(new SolidBrush(Color.Black), 2); for (int x = 0; x < 6; x++) graph.DrawLine(linePen, new Point(r.Next(0, 199), r.Next(0, 59)), new Point(r.Next(0, 199), r.Next(0, 59))); //將圖片保存到輸出流中 basemap.Save(context.Response.OutputStream, ImageFormat.Gif); context.Session["CheckCode"] = s.ToString(); //如果沒有實現IRequiresSessionState，則這裡會出錯，也無法生成圖片 context.Response.End(); } public bool IsReusable { get { return true; } }}

需要特別注意的是，Handler類不僅需要實現 IHttpHandler介面(這個顯然)，為了在這個Handler類中使用SessionState，還需要實現IRequiresSessionState介面，對於這個介面，MSDN的解釋是這樣的：Specifies that the target HTTP handler requires read and write access to session-state values. This is a marker interface and has no methods.(翻譯過來是：指定當前Http Handler需要對SessionState值的讀寫訪問權。這是一個標記介面，沒有任何方法)。

而實際上，IRequiresSessionState的介面定義是這樣的：

public interface IRequiresSessionState{}

可見，這個介面沒有任何需要實現的方法或屬性，大家只要記得：如果想在HttpHandler中使用SessionState，必須實現這個介面，實際上也就是在類的標頭將這個介面加進去。

Step.3 新建一個ImageCode.aspx頁面，在HTML代碼中寫下：

OK，在瀏覽器中打開ImageCode.aspx，應該可以看到如下所示：

利用HttpHandler創建自定義後綴Rss源

RSS如今已經可以說是隨處可見，而RSS的實現方式，通常是在一個.aspx的CodeBehind文件中寫一個XML文件，然後載入到Response的OutputStream中， Rss源通常是Rss.aspx這種形式的。通過第一章學到的ISAPI的知識，再結合本章學到的關於HttpHandler的知識，很容易想到：我們可以自定一個以 .rss 作為後綴名的文件來實現 Rss 源，比如說Article.rss。現在我們就一步步來實現它：

NOTE：關於RSS的更多內容，可以參閱我編譯的在Web站點中創建和使用RSS源。本文不再解釋Rss是什麼，如何創建Rss源，為了文章的獨立性，僅給出創建過程。

Step.1 創建範例資料庫

Create Table RssSample( SampleId Int Identity(1,1) Not Null, Title Varchar(100) Not Null Constraint uq_Title Unique, Author Varchar(50) Not Null, PubDate DateTime Not Null Default GetDate(), [Description] Varchar(500) Not Null, Link Varchar(150) Not Null Constraint pk_RssSample Primary Key(SampleId))-- 插入範例數據Insert Into RssSample(Title, Author, [Description], Link)Values("標題1", "作者1", "文章摘要1", "http://127.0.0.1/#" )-- 省略 ....

Step.2 建立站點，在App_Code目錄下建立RssFeedsLib.cs文件。

using System;using System.Data;using System.Data.SqlClient;using System.IO;using System.Web;using System.Xml;using System.Text;namespace RssFeadsLib { public class RssGenerator { public static string GetRSS() { MemoryStream ms = new MemoryStream(); XmlTextWriter writer = new XmlTextWriter(ms, null); SqlConnection conn = new SqlConnection("Data Source=.;Initial Catalog=Sample;User ID=sa;Password=sa"); //修改這裡成你的資料庫連接 SqlCommand cmd = new SqlCommand("select * from RssSample order by pubdate desc", conn); conn.Open(); SqlDataReader reader = cmd.ExecuteReader(); writer.WriteStartElement("rss"); writer.WriteAttributeString("version", "2.0"); writer.WriteStartElement("channel"); // Channel 下的結點靜態寫入 writer.WriteElementString("title", "TraceFact.Net 技術文章"); writer.WriteElementString("link", "http://www.tracefact.net"); writer.WriteElementString("description", "Dedicated to asp.net..."); writer.WriteElementString("copyright", "Copyright (C) 2007"); writer.WriteElementString("generator", "My RSS Generator"); // Item 結點從資料庫讀取 while (reader.Read()) { writer.WriteStartElement("item"); writer.WriteElementString("author", reader.GetString(reader.GetOrdinal("Author"))); writer.WriteElementString("title", reader.GetString(reader.GetOrdinal("title"))); writer.WriteElementString("link", reader.GetString(reader.GetOrdinal("Link"))); writer.WriteElementString("description", reader.GetString(reader.GetOrdinal("Description"))); writer.WriteElementString("pubDate", reader.GetDateTime(reader.GetOrdinal("PubDate")).ToString(@"ddd, dd MMM yyyy 12:00:00 tt ")); writer.WriteEndElement(); } writer.WriteEndElement(); writer.WriteEndElement(); reader.Close(); conn.Close(); writer.BaseStream.Flush(); writer.Flush(); ms.Flush(); // 將流轉換成String並返回 byte[] data = new byte[ms.Length]; ms.Seek(0, SeekOrigin.Begin); ms.Read(data, 0, data.Length); ms.Close(); return UTF8Encoding.UTF8.GetString(data); } }}

Step.3 創建可以處理 .rss 後綴名的 RssHandler

我們在這個 RssFeedsLib命名空間下，再添加一個類，這個類用於處理對 .rss 後綴名文件的Http請求。

public class RSSHandler:IHttpHandler{ public bool IsReusable { get {return false;} } public void ProcessRequest(HttpContext context){ context.Response.ContentType = "text/xml"; string str = RssGenerator.GetRSS(); context.Response.Write(str); }}

Step.4 在Web.config中進行配置

NOTE：因為這個類和命名空間位於App_Code中，這裡就不需要再手動編譯RssFeadsLib.cs然後將編譯好的.dll應用程序集放到Bin目錄中了。至於為什麼可以這樣，將會在《Asp.Net 構架與安全機制 Part.5 – 頁面生存周期與編譯模型》中解釋。

Step.5 在IIS 對ISAPI進行設置。

應該還記得在Part.1中如何在IIS中設置ISAPI來進行文件與處理程序映射：

打開IIS，選擇本範例所用的站點，右鍵，選擇「屬性」。
選擇「主目錄」選項卡，點擊「配置...」按鈕。
點擊「添加」，設置「可執行文件」為「C:WINDOWSMicrosoft.NETFrameworkv2.0.50727aspnet_isapi.dll」，設置「擴展名」為「.rss」，點「確定」。
注意，不要勾選「檢查文件是否存在」複選框，這樣不用創建文件，只要在地址欄輸入任意以.rss後綴結尾的文件名，均會交由上面創建的Handler去處理，而不管這個文件是否存在，也不管請求的是Article.rss還是Sample.rss。

進行了這些設置以後，現在IIS就知道如何去處理對.rss後綴名文件的請求了。

Step.6 測試範例

這個時候，隨便打開一個頁面，比如空白的Default.aspx，然後我們在地址欄將文件改為：Article.rss(改成abc.rss也是一樣)，敲回車，應該可以看到如下的畫面。

IHttpHandlerFactory 概述

現在假設我們有這樣的需求，我們不僅想要處理 .rss 後綴名，還想要能夠處理 .atom後綴名，假設處理atom的類命名為AtomHandler，那麼我們的Web.config該如何設置呢？我想應該是這樣的：

如果我們有很多個HttpHandler分別映射不同後綴名的請求，這樣我們的Web.config會變得很冗長，或者，我們只有在程序運行時才能確切地知道使用哪個Handler，這個時候，可以考慮實現 IHttpHandlerFactory來完成這一過程。

IHttpHandlerFactory的定義是這樣的：

public interface IHttpHandlerFactory{ IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated); void ReleaseHandler(IHttpHandler handler);}

可見，需要實現兩個方法，分別是 GetHandler() 和 ReleaseHandler()。

GetHandler()，返回實現了IHttpHandler介面的類的實例。

ReleaseHandler()，使得Factory可以重複使用一個已經存在的Handler實例。

對於上面 .atom 和 .rss 的問題，我們可以這樣來實現 IHttpHandlerFactory介面：

class HandlerFactory:IHttpHandlerFactory{ public IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated){ string path = context.Request.PhysicalPath; if (Path.GetExtension(path) == ".rss"){ return new RSSHandler(); } if (Path.GetExtension(path) == ".atom"){ return new ATOMHandler(); } return null; } public void ReleaseHandler(IHttpHandler handler){ }}

這時，在Web.Config 中<system.web>節點下進行如下設置即可：

但是，這不能簡化IIS中ISAPI的設置，還是需要手動去對.rss和.atom分別設置。

總結

在本文中，我們首先討論了aspnet_isapi.dll 如何將對不同後綴名文件的請求分發給相應的處理程序，如何查看Framework默認的處理程序Handler。

然後，我們通過三個實例，圖片防盜鏈、圖片驗證碼、處理自定義後綴名請求，詳細講解了IHttpHandler的實現方法和使用過程。

最後，我向大家概要地介紹了IHttpHandlerFactory介面。

第三回：引言

Http 請求處理流程和 Http Handler 介紹這兩篇文章里，我們首先了解了Http請求在伺服器端的處理流程，隨後我們知道Http請求最終會由實現了IHttpHandler介面的類進行處理(應該記得Page類實現了IHttpHandler)。從 Http 請求處理流程一文的最後的一幅圖中可以看到，在Http請求由IHttpHandler處理之前，它需要通過一系列的Http Module；在請求處理之後，它需要再次通過一系列的Http Module，那麼這些Http Module是如何組成的？用來做什麼呢？本文將對Http Module作以介紹。

Http Module概述

暫時先不考慮我們自己實現Http Module的情況。在.Net中，Http Module 是實現了IHttpModule介面的程序集。IHttpModule 介面本身並沒有什麼好大寫特寫的，由它的名字可以看出，它不過是一個普普通通的介面而已。實際上，我們關心的是實現了這些介面的類，如果我們也編寫代碼實現了這個介面，那麼有什麼用途。一般來說，我們可以將Asp.Net中的事件分成三個級別，最頂層是應用程序級事件、其次是頁面級事件、最下面是控制項級事件，事件的觸發分別與應用程序周期、頁面周期、控制項周期緊密相關。而 Http Module 的作用是與應用程序事件密切相關的。

我們通過Http Module在Http請求管道(Pipeline)中註冊期望對應用程序事件做出反應的方法，在相應的事件觸發的時候(比如說BeginRequest事件，它在應用程序收到一個Http請求並即將對其進行處理時觸發)，便會調用Http Module註冊了的方法，實際的工作在這些方法中執行。.Net 本身已經有很多的Http Module，其中包括表單驗證Module(FormsAuthenticationModule)， Session 狀態Module(SessionStateModule)，輸出緩存Module (OutputCacheModule)等。

註冊 Http Module

在註冊我們自己編寫的 Http Module 之前，先來看看Asp.Net中已經有的HttpModule。與 Http Handler類似，我們需要打開機器上C:WINDOWSMicrosoft.NETFramework v2.0.50727CONFIG 目錄下的 web.config 文件。找到 <httpModules/> 結點，應該可以看到下面的內容：

我們先從結點上看，type屬性與上一節所說的http handler結點的type屬性類似，都代表了相應的程序集。但是，與http handler 不同，module只提供了一個name屬性，沒有諸如 path這樣指定某一特定(或者用通配符 * 代表某一種類)文件的處理程序。這是與Module的特點相關的，我們知道 module 是響應應用程序周期中觸發的事件，對於所有提交到aspnet_isapi.dll的請求都一樣，即便請求只是像類似http://www.tracefact.net/images/logo.gif 這樣獲取一張圖片而已(對ISAPI進行過設置以後，默認aspnet_isapi.dll不接手圖片文件)。

與Http handler類似，在這冊我們自己的http module 時，假設類名為ModuleDemo，位於myNameSpace命名空間下，程序集名稱為myDll，我們只需將myDll.dll拷貝到Bin目錄下，並在站點的 web.config 文件 system.web 結點下創建 httpModules 結點：

<system.web> <httpModules> <add name="CustomModuleName" type="myNameSpace.ModuleDemo, myDll"/> </httpModules></system.web>

type屬性由分號「,」分為兩部分，前面是命名空間及類名，也就是類型名；後面是程序集名。如果我們將代碼創建在App_Code目錄中，則不需要再指定程序集名。

name屬性由我們自己命名，不一定與類名相同，此處我將它命名為「CustomModuleName」。我們可以通過應用程序(HttpApplication)的Modules屬性獲取HttpModuleCollection集合，然後通過name屬性，進一步獲取HttpModule對象。

通過name屬性，我們還可以在global.asax中文件中編寫自定義HttpModule暴露出的事件的處理程序，它採用的格式是：void ModuleName_EventName(object sender, EventArgs e)。我們將在後面做更詳細介紹。

Asp.Net 內置的 Http Modules

下面這張表格列出了C:WINDOWSMicrosoft.NETFramework v2.0.50727CONFIG下的Web.Config中的 Asp.Net 內置的Http Modules 及其主要作用。

名稱	類型	功能
OutputCache	System.Web.Caching.OutputCacheModule	頁面級輸出緩存
Session	System.Web.SessionState.SessionStateModule	Session狀態管理
WindowsAuthentication	System.Web.Security.WindowsAuthenticationModule	用集成Windows身份驗證進行客戶端驗證
FormsAuthentication	System.Web.Security.FormsAuthenticationModule	用基於Cookie的窗體身份驗證進行客戶端身份驗證
PassportAuthentication	System.Web.Security.PassportAuthenticationModule	用MS護照進行客戶身份驗證
RoleManager	System.Web.Security.RoleManagerModule	管理當前用戶角色
UrlAuthorization	System.Web.Security.UrlAuthorizationModule	判斷用戶是否被授權訪問某一URL
FileAuthorization	System.Web.Security.FileAuthorizationModule	判斷用戶是否被授權訪問某一資源
AnonymousIdentification	System.Web.Security.AnonymousIdentificationModule	管理Asp.Net應用程序中的匿名訪問
Profile	System.Web.Profile.ProfileModule	管理用戶檔案文件的創立及相關事件
ErrorHandlerModule	System.Web.Mobile.ErrorHandlerModule	捕捉異常，格式化錯誤提示字元，傳遞給客戶端程序

我們將在後面用編程的方式來查看它。

IHttpModule介面

看了這麼多理論知識，本節將開始動手寫點程序，實現自己的Http Module。我們首先需要看下IHttpModule 介面，它包括下面兩個方法：

public void Init(HttpApplication context);public void Dispose();

Init()：這個方法接受一個HttpApplication對象，HttpApplication代表了當前的應用程序，我們需要在這個方法內註冊 HttpApplication對象暴露給客戶端的事件。可見，這個方法僅僅是用來對事件進行註冊，而實際的事件處理程序，需要我們另外寫方法。

整個過程很好理解：

當站點第一個資源被訪問的時候，Asp.Net會創建HttpApplication類的實例，它代表著站點應用程序，同時會創建所有在Web.Config中註冊過的Module實例。
在創建Module實例的時候會調用Module的Init()方法。
在Init()方法內，對想要作出響應的HttpApplication暴露出的事件進行註冊。(僅僅進行方法的簡單註冊，實際的方法需要另寫)。
HttpApplication在其應用程序周期中觸發各類事件。
觸發事件的時候調用Module在其Init()方法中註冊過的方法。

NOTE：如果你不了解事件註冊等相關內容，請參閱 C#中的委託與事件一文。

Dispose()：它可以在進行垃圾回收之前進行一些清理工作。

綜上所述：實現一個 IHttpModule 的模板一般是這樣的：

public class ModuleDemo:IHttpModule{ public void Init(HttpApplication context) { // 註冊HttpApplication應用程序 BeginRequest 事件 // 也可以是其他任何HttpApplication暴露出的事件 context.BeginRequest += new EventHandler(context_BeginRequest); } void context_BeginRequest(object sender, EventArgs e) { HttpApplication application = (HttpApplication)sender; HttpContext context = application.Context; // 做些實際的工作，HttpContext對象都獲得了，剩下的基本可以自由發揮了 } public void Dispose() { }}

通過Http Module向Http請求輸出流中寫入文字

本例中，我們僅用BeginRequest事件和 EndRequest 事件對 Http Module 的使用作以說明。我們通過這個範例，了解 Http Module 基本的使用方法。

首先，請創建一個新的站點，在App_Code目錄中添加類文件： ModuleDemo.cs：

public class ModuleDemo:IHttpModule{ // Init方法僅用於給期望的事件註冊方法 public void Init(HttpApplication context) { context.BeginRequest += new EventHandler(context_BeginRequest); context.EndRequest += new EventHandler(context_EndRequest); } // 處理BeginRequest 事件的實際代碼 void context_BeginRequest(object sender, EventArgs e) { HttpApplication application = (HttpApplication)sender; HttpContext context = application.Context; context.Response.Write("<h1 style="color:#00f">來自HttpModule 的處理，請求到達</h1><hr>"); } // 處理EndRequest 事件的實際代碼 void context_EndRequest(object sender, EventArgs e) { HttpApplication application = (HttpApplication)sender; HttpContext context = application.Context; context.Response.Write("<hr><h1 style="color:#f00">來自HttpModule的處理，請求結束</h1>"); } public void Dispose() { }}

上面的代碼很簡單，它註冊了 HttpApplication實例的 BeginRequest 事件和 EndRequest事件，事件處理方法的作用僅僅是在http請求開始和結束的時候，給http請求的輸入流中分別寫入不同的內容。

接下來在 Web.config 的 System.web 結點中寫入以下內容：

<system.web> <httpModules> <add name="MyModule" type="ModuleDemo" /> </httpModules></system.web>

然後，打開建立站點時自動創建的 Default.aspx文件，在裡面打幾個字，為了做區分，我輸入的是：位於.aspx頁面上的文字。然後，我們在瀏覽器中打開它，應該會看到像這樣：

然後我們再新建一個 Default2.aspx，在瀏覽器中瀏覽，可以看到，兩個頁面的效果相同。這說明對於不同的兩個文件，http Module都起了作用，可見它確實是位於應用程序級，而非頁面級。

現在，我們再打開站點中的一張圖片文件，發現顯示出的是一個紅叉叉，為什呢？因為Http Module 針對是http 請求，而不是某個或某一類文件，所以當請求一張圖片的時候，我們編寫的http Module依然會起作用，將文字插入到二進位圖片中，破壞了文件格式，自然只能顯示紅叉叉了。

NOTE：如果你發現你的圖片顯示正常，請不要驚訝，事情是這樣的：回想一下第一節我們討論到的，對於圖片文件，由IIS直接處理，並不會交由aspnet_isapi.dll，所以，Module無法捕獲對於圖片類型文件的請求。解決方法就是在IIS中進行設置一下。這裡需要提請注意的是：如果你使用Vs2005自帶的Local Server，那麼你無需對IIS進行設置，所有的不論圖片還是任何文件類型，都會交由aspnet_isapi.dll處理。

遍歷Http Module集合

現在，我們通過遍歷 HttpModuleCollection 集合來查看註冊給應用程序的所有 Http Module 的名稱。

新建一個文件 RegisteredModules.aspx，在代碼後置文件中添加如下方法：

private string ShowModules() { HttpApplication app = Context.ApplicationInstance; //獲取當前上下文的HttpApplication環境 HttpModuleCollection moduleCollection = app.Modules; //獲取所有Module集合 // 獲取所有的 Module 名稱 string[] moduleNames = moduleCollection.AllKeys; System.Text.StringBuilder results = new System.Text.StringBuilder(); //遍歷結果集 foreach (string name in moduleNames) { // 獲得Module名稱 results.Append("<b style="color:#800800">名稱：" + name + "</b><br />"); // 獲得Module類型 results.Append("類型：" + moduleCollection[name].ToString() + "<br />"); } return results.ToString();}

然後在Page_Load方法中輸出一下：

protected void Page_Load(object sender, EventArgs e){ Response.Write(ShowModules());}

我們應該可以看到下面這樣的畫面：

與之前列出的那張表格比較一下，可以看出是幾乎完全一致的(多了一個DefaultAuthentication)。另外注意上圖的倒數第四行，那不是我們自己定義的Module么？name為MyModule，類型為ModuleDemo。

Global.asax文件與 Http Module

早在asp時代，大家就知道這個文件了。它主要用於放置對於應用程序事件或者 Session事件的響應程序。大家熟悉的有Application_Start、Application_End、Session_Start、Session_End 等。

在asp.net中，Glabal不僅可以註冊應用程序和Session事件，還可以註冊Http Module暴露出的事件；不僅可以註冊系統Module的事件，也可以註冊我們自己義的Module暴露出的事件。在具體介紹之前，這裡需要首先注意兩點：

在每處理一個Http請求時，應用程序事件都會觸發一遍，但是Application_Start和 Application_End 例外，它僅在第一個資源文件被訪問時被觸發。
Http Module無法註冊和響應Session事件，對於Session_Start 和 Session_End，只能通過Glabal.asax來處理。

好了，我們現在修改之前 ModuleDemo 范常式序，給它像下面這樣給它添加一個事件(為了使程序簡潔一些，我做了簡化)：

public class ModuleDemo : IHttpModule { // 聲明一個事件 public event EventHandler ExposedEvent; // Init方法僅用於給期望的事件註冊方法 public void Init(HttpApplication context) { context.BeginRequest += new EventHandler(context_BeginRequest); } // 處理BeginRequest 事件的實際代碼 void context_BeginRequest(object sender, EventArgs e) { HttpApplication application = (HttpApplication)sender; HttpContext context = application.Context; context.Response.Write("<h3 style="color:#00f">來自HttpModule的處理，請求到達</h3><hr>"); OnExposedEvent(new EventArgs()); // 調用方法 } protected override void OnExposedEvent(EventArgs e) { if (ExposedEvent != null) // 如果Global中有註冊 ExposedEvent(this, e); // 調用註冊了的方法 } public void Dispose() { }}

接下來，我們在站點中創建一個 Global.asax 文件，在裡面添加如下代碼，注意到格式是：void 模塊名_事件名(object sender, EventArgs e)。

void MyModule_ExposedEvent(object sender, EventArgs e){ Response.Write("<h3 style="color:#800800">來自 Global.asax 的文字</h2>");}

現在，我們打開之前的頁面，應該可以見到這樣，可見，我們成功的將 Glabal.asax文件與我們自己定義的Http Module所暴露出的事件 ExposedEvent 聯繫到了一起：

總結

本文簡單地介紹了什麼是Http Module。我們首先了解了Http Module的作用，然後查看了Asp.Net 內置的Module，接著我們介紹了IHttpModule介面，並通過了一個簡單的範例實現了此介面，最後我們討論了 Http Module與 Global.asax 文件的聯繫。

本文僅僅是對IHttpModule作以簡單介紹，對其更多的實際應用，會在後續文章中補充。

希望這篇文章能給你帶來幫助！

本文的源代碼下載：http://www.tracefact.net/sourcecode/Introduction-to-HttpModule.rar 引：http://www.cnblogs.com/JimmyZhang/category/101697.html