第一回:
引言我查閱過不少Asp.Net的書籍,發(fā)現(xiàn)大多數(shù)作者都是站在一個比較高的層次上講解Asp.Net。他們耐心、細(xì)致地告訴你如何一步步拖放控件、設(shè)置控件屬性、編寫CodeBehind代碼,以實現(xiàn)某個特定的功能。 這種做法,實際上是回答了“如何去做”的問題,卻沒有回答“為什么可以這樣做”的問題。 盡管我很推崇 悉江華 先生的《圣殿祭祀的Asp.Net開發(fā)詳解》一書,但當(dāng)我翻看了一下其對角色(Role) 和 用戶(Member)的講解時,我決定跳過去直接讀后面的章節(jié)。因為我發(fā)現(xiàn)他也隨了大流,對這部分的講解停留在“如何去做”的層面上。我相信像悉先生 這樣的牛人是不可能不了解底層運作原理的,僅僅是因為那本書原本就已經(jīng)很厚了吧。 當(dāng)你按“如何去做”所講解的內(nèi)容去開發(fā)程序的時候,對于你的用戶,你仍是一名程序員;但對于實現(xiàn)了MembershipProvider 和 RoleProvider 抽象類的微軟開發(fā)人員來說,你已經(jīng)成了他們的一個用戶。 NOTE:我既不反對一些作者只講解“如何去做”,也不反對你只學(xué)“如何去做”,這樣也有它的好處,就是可以快速開發(fā)。我只是建議多掌握一點底層知識,對一些問題會有更好的理解。 希望通過這一系列文章的講解,可以讓你更好的理解Asp.Net的運作原理和做以了解。 Http請求處理流程概述思考“為什么在地址欄輸入www.就可以看到張子陽的個人空間?”,類似于思考“為什么蘋果是往地上掉不是往天上飄?”。對于普通訪問者來說,這就像每天太陽東邊升起西邊落下一樣是理所當(dāng)然的;對于很多程序員來說,認(rèn)為這個與己無關(guān),不過是系統(tǒng)管理員或者網(wǎng)管員的責(zé)任。畢竟,IIS是 Windows 的一個組件,又不是 Asp.Net 的一個組成部分。而實際上,從你輕拍回車到頁面呈現(xiàn)在你眼前的十分之一秒內(nèi),IIS和.Net Framework已經(jīng)做了大量的幕后工作。 你可能覺得了解這些幕后工作是如何運作的無關(guān)緊要,作為程序員的你只要保證開發(fā)出的程序可以高效地運行就可以了。然而,在開發(fā)過程中,你卻發(fā)現(xiàn)常常需要使用諸如 HttpContext 這樣的類。這個時候,你可曾思考過這些類的構(gòu)成和類的實體是如何創(chuàng)建的?你可能簡單地回答:HttpContext代表當(dāng)前請求的一個上下文環(huán)境??赡阌种繧IS 、Framework、Asp.Net 是如何協(xié)同工作處理每個Http請求、如何區(qū)分不同的請求、IIS、Framework、Asp.Net三者之間的數(shù)據(jù)如何流動么? 回答上面這些問題,首先需要了解IIS是如何處理頁面請求的,這也是理解 Form驗證模式和Windows 驗證模式 的基礎(chǔ)。 Http請求剛剛到達(dá)服務(wù)器的時候當(dāng)服務(wù)器接收到一個 Http請求的時候,IIS 首先需要決定如何去處理這個請求(NOTE:服務(wù)器處理一個.htm頁面和一個.aspx頁面肯定是不一樣的么)。那IIS依據(jù)什么去處理呢?―― 根據(jù)文件的后綴名。 服務(wù)器獲取所請求的頁面(NOTE:也可以是文件,比如 jimmy.jpg)的后綴名以后,接下來會在服務(wù)器端尋找可以處理這類后綴名的應(yīng)用程序,如果IIS找不到可以處理此類文件的應(yīng)用程序,并且這個文件也沒有受到服務(wù)器端的保護(hù)(NOTE:一個受保護(hù)的例子就是 App_Code中的文件,一個不受保護(hù)的例子就是你的js腳本),那么IIS將直接把這個文件返還給客戶端。 能夠處理各種后綴名的應(yīng)用程序,通常被稱為 ISAPI 應(yīng)用程序(NOTE:Internet Server Application Programe Interface,互聯(lián)網(wǎng)服務(wù)器應(yīng)用程序接口)。雖然這 ISAPI 聽上去還挺氣派,也算是“應(yīng)用程序”呢,但仔細(xì)看看它的全稱就明白了:它實際上只是一個接口,起到一個代理的作用,它的主要工作是映射所請求的頁面(文件) 和與此后綴名相對應(yīng)的實際的處理程序。 讓我們更進(jìn)一步地看一下 ISAPI ,看看它到底是什么樣子,請按下面的步驟進(jìn)行:
你應(yīng)該會看到如下的畫面: 圖1. 應(yīng)用程序配置 很清楚地就可以看到,所有IIS所能處理,或者叫 ISAPI 所提供代理服務(wù)的 文件類型 及其相對應(yīng)的實際的后臺處理程序都在這里清楚地列出來了。 我們找到 .aspx 的應(yīng)用處理程序,然后點“編輯”,會出現(xiàn)下面的畫面: 圖2. 編輯.aspx文件的處理程序
一路看到這里,可以看出,所有的.aspx文件實際上都是由 aspnet_isapi.dll 這個程序來處理的,當(dāng)IIS把對于.aspx頁面的請求提交給了aspnet_isapi.dll以后,它就不再關(guān)心這個請求隨后是如何處理的了?,F(xiàn)在我們應(yīng)該知道:Asp.Net 只是服務(wù)器(IIS)的一個組成部分而已,它是一個 ISAPI擴(kuò)展。 這里需要注意兩點:
理解宿主環(huán)境(Hosting)從本質(zhì)上講,Asp.Net 主要是由一系列的類組成,這些類的主要目的就是將Http請求轉(zhuǎn)變?yōu)閷蛻舳说捻憫?yīng)。HttpRuntime類是Asp.Net的一個主要入口,它有一個稱作 ProcessRequest 的方法,這個方法以一個 HttpWorkerRequest 類作為參數(shù)。HttpRuntime 類幾乎包含著關(guān)于單個 Http請求的所有信息:所請求的文件、服務(wù)器端變量、QueryString、Http 頭信息 等等。Asp.Net 使用這些信息來加載、運行正確的文件,并且將這個請求轉(zhuǎn)換到輸出流中,一般來說,也就是HTML頁面。 NOTE:二般來說,也可以是張圖片。 當(dāng) Web.config文件的內(nèi)容發(fā)生改變 或者 .aspx文件發(fā)生變動的時候,為了能夠卸載運行在同一個進(jìn)程中的應(yīng)用程序(NOTE:卸載也是為了重新加載),Http請求被分放在相互隔離的應(yīng)用程序域中。 NOTE:可能你以前就聽過應(yīng)用程序域,但是不了解怎么回事,應(yīng)用程序域就是 AppDomain。 對于IIS來說,它依賴一個叫做 HTTP.SYS 的內(nèi)置驅(qū)動程序來監(jiān)聽來自外部的 HTTP請求。在操作系統(tǒng)啟動的時候,IIS首先在HTTP.SYS中注冊自己的虛擬路徑。 NOTE:實際上相當(dāng)于告訴HTTP.SYS哪些URL是可以訪問的,哪些是不可以訪問的。舉個簡單的例子:為什么你訪問不存在的文件會出現(xiàn) 404 錯誤呢?就是在這一步確定的。 如果請求的是一個可訪問的URL,HTTP.SYS會將這個請求交給 IIS 工作者進(jìn)程。 NOTE:IIS6.0中叫做 w3wp.exe,IIS5.0中叫做 aspnet_wp.exe。 每個工作者進(jìn)程都有一個身份標(biāo)識 以及 一系列的可選性能參數(shù)。 NOTE:可選性能參數(shù),是指諸如 回收機制的設(shè)置、超時時間設(shè)置 等等。 接下來進(jìn)行的事情就是上一章節(jié)講述的 ISAPI 了。 NOTE:這部分的內(nèi)容相關(guān)性比較強,為了讓大家好理解,我最后還是決定把 ISAPI 放到前面了,可能全系列完成的時候會再調(diào)整吧。 除了映射文件與其對應(yīng)的處理程序以外,ISAPI 還需要做一些其他的工作:
接下來才是程序員通常編寫的代碼所完成的工作了,然后,IIS 接收返回的數(shù)據(jù)流,并重新返還給 HTTP.SYS,最后,HTTP.SYS 再將這些數(shù)據(jù)返回給客戶端瀏覽器。 OK,現(xiàn)在你看到張子陽的空間主頁了。 圖3.Asp.Net 的宿主環(huán)境 理解管道(Pipeline)在前面兩章中,我們在一個相對比較低的層次上討論了從發(fā)出Http請求到看到瀏覽器輸出這轉(zhuǎn)瞬即逝的十分之一秒內(nèi)IIS和 Framework 所做的事情。但是我們忽略了一個細(xì)節(jié):程序員編寫的代碼是如何在這一過程中銜接的,本章我們就來看看這個問題。 當(dāng)Http請求進(jìn)入 Asp.Net Runtime以后,它的管道由托管模塊(NOTE:Managed Modules)和處理程序(NOTE:Handlers)組成,并且由管道來處理這個 Http請求。 圖4. 理解 Http 管道 我們按編號來看一下這幅圖中的數(shù)據(jù)是如何流動的。 1. HttpRuntime將Http請求轉(zhuǎn)交給 HttpApplication,HttpApplication代表著程序員創(chuàng)建的Web應(yīng)用程序。HttpApplication創(chuàng)建針對此Http請求的 HttpContext對象,這些對象包含了關(guān)于此請求的諸多其他對象,主要是HttpRequest、HttpResponse、HttpSessionState等。這些對象在程序中可以通過Page類或者Context類進(jìn)行訪問。、 2. 接下來Http請求通過一系列Module,這些Module對Http請求具有完全的控制權(quán)。這些Module可以做一些執(zhí)行某個實際工作前的事情。 3. Http請求經(jīng)過所有的Module之后,它會被HttpHandler處理。在這一步,執(zhí)行實際的一些操作,通常也就是.aspx頁面所完成的業(yè)務(wù)邏輯。可能你會覺得在創(chuàng)建.aspx頁面并沒有體會到這一過程,但是,你一定知道,.aspx 頁面繼承自Page類,我們看一下Page類的簽名: public class Page : TemplateControl, IHttpHandler{ 可以看到,Page類實現(xiàn)了IHttpHandler接口,HttpHandler也是Http請求處理的最底層。 4.HttpHandler處理完以后,Http請求再一次回到Module,此時Module可以做一些某個工作已經(jīng)完成了之后的事情。 NOTE:注意我用紅色標(biāo)識的字,然后回想一下:Asp.Net 中是不是有眾多的 Inserting 、Inserted 之類成對的事件?其實,這里講述的就是為什么Asp.Net可以將一個Insert操作分成前后兩部分,然后再分別進(jìn)行事件攔截的幕后原理。 如果我們將注意力只集中在Http請求、HttpHandler和HttpModule上,不去考慮HttpContext和HttpApplication,那么圖4.可以簡化成下面這樣: 圖5.Http請求在HttpHandler 和 HttpModule 中的流動方向 總結(jié)本文中,我首先概要介紹了這系列文章將要為大家講述的主題。然后,我提出了部分程序員存在的一個問題:在一個比較高的層次上學(xué)習(xí)和使用Asp.Net。 隨后,我以一個訪問我個人空間首頁的例子,引出了本文主要講述的三個內(nèi)容:
希望這篇文章能給你帶來幫助。 第二回:引言在 Part.1 Http請求處理流程 一文中,我們了解了Http請求的處理過程以及其它一些運作原理。我們知道Http管道中有兩個可用接口,一個是IHttpHandler,一個是IHttpModule,但在Part.1中,我并沒有詳細(xì)講述如何對它們進(jìn)行編程,只是輕描淡寫地一筆帶過。所謂學(xué)以致用,前面已經(jīng)介紹了不少概念和原理。在本文中,我們通過幾個范例來了解 IHttpHandler,看看掌握這些原理的實際用途。 IHttpHandler 概述可能和我一樣,很多Asp.Net開發(fā)人員都有過Asp的背景,以至于我們在開發(fā)程序的時候,通常都是在“頁面級”上思考,也就是說我們現(xiàn)在正在做的這個頁面應(yīng)該有什么樣的功能,是進(jìn)行一個問卷調(diào)查還是一個數(shù)據(jù)庫查詢等等。而很少在“請求級”思考,考慮有沒有辦法來通過編碼的方式來操控一個Http請求。 實際上,F(xiàn)ramework提供了一系列的接口和類,允許你對于Http請求進(jìn)行編程,而實現(xiàn)這一操作的一個主要的接口,就是 IHttpHandler(另一個是IHttpModule)。 應(yīng)該還記得第一節(jié)中我們提到過 ISAPI,它根據(jù)文件名后綴把不同的請求轉(zhuǎn)交給不同的處理程序。但是仔細(xì)看看就會發(fā)現(xiàn):幾乎一大半的文件都交給 aspnet_isapi.dll 去處理了。很明顯,aspnet_isapi.dll 不可能對每種文件采用同一種方式處理,那么 aspnet_isapi.dll 是如何更進(jìn)一步處理不同的文件,交由誰去處理呢?為了搞清楚這個問題,我們需要打開機器上C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\ 目錄下的web.config 文件。 NOTE:我查閱了很多資料,都說是在 machine.config 中,但實際上 v2.0.50727 下的machine.config中httpHandlers結(jié)點是這樣的:<httpHandlers />,并沒有給出詳細(xì)的處理程序,在Web.config中才能看到。而v1.1.4322 下的machine.config中卻有。 找到httpHandlers結(jié)點,應(yīng)該可以看到如下這樣的代碼(做了省略): <httpHandlers> 可以看到,在<httpHandlers>結(jié)點中將不同的文件類型映射給不同的Handler去處理,對于.aspx來說,是由System.Web.UI.PageHandlerFactory來處理。而對于.cs來說,是由System.Web.HttpForbiddenHandler 處理,從ForbiddenHandler名字中出現(xiàn)的Forbidden (翻譯過來是“禁止”)可以看出,這個Handler可以避免我們的源碼被看到。 NOTE:System.Web.UI.PageHandlerFactory 是一個IHttpHandlerFactory,而不是一個單一的HttpHandler,IHttpHandlerFactory用來做什么后面會說明。 上面列出的是.Net Framework在處理Http請求時的所采用的默認(rèn)Handler。而如果我們要用編程的方式來操控一個Http請求,我們就需要實現(xiàn)IHttpHandler接口,來定制我們自己的需求。 IHttpHandler的定義是這樣的: public interface IHttpHandler{ 由上面可以看出IHttpHandler要求實現(xiàn)一個方法和一個屬性。其中 ProcessRequest,從名字(處理請求)看就知道這里應(yīng)該放置我們處理請求的主要代碼。 IsReusable屬性,MSDN上是這樣解釋的:獲取一個值,該值指示其他請求是否可以使用 IHttpHandler 實例。也就是說后繼的Http請求是不是可以繼續(xù)使用實現(xiàn)了該接口的類的實例,一般來說,我把它設(shè)置成true。 那么實現(xiàn)此接口的類形式應(yīng)該是這樣的: public class CustomHandler : IHttpHandler{ 而為了能使用這個自定義的HttpHandler,我們需要在應(yīng)用程序目錄下的Web.config中注冊它。 <system.web> 應(yīng)該發(fā)現(xiàn)這與之前在C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\目錄下web.config中看到的幾乎完全一樣。這里,path指的是請求的文件名稱,可以使用通配符擴(kuò)大范圍,也可以明確指定這個handler僅用于處理某個特定的文件(比如說:filename.aspx)的請求。verb指的是請求此文件的方式,可以是post或get,用*代表所有訪問方式。type屬性由“,”分隔成兩部分,第一部分是實現(xiàn)了接口的類名,第二部分是位于Bin目錄下的編譯過的程序集名稱。 NOTE:如果你新建一個項目,并且在項目下創(chuàng)建HandlerTest.cs,然后讓站點引用該項目,那么在生成解決方案的時候會自動將編譯好的.dll文件添到Bin目錄中。 使用HttpHandler實現(xiàn)圖片防盜鏈有了之前這么多的準(zhǔn)備知識,實現(xiàn)現(xiàn)在的目標(biāo)就容易得多了: NOTE:這個例子,以及下面的一個例子均來自于《Maximizing ASP.NET Real World, Object-Oriented Development》一書: Step.1:創(chuàng)建文件 CustomHandler.cs,代碼如下:using System; Step.2 編譯這個文件csc /t:library /r:System.Web.dll CustomHandler.cs Step.3 將編譯好的 CustomHandler.dll 拷貝到站點的 Bin 目錄下。Step.4 在Web.Config 中注冊這個Handler。<system.web> OK,諸位可以按步驟自行測試一下,這里就不贅述了。 通過IhttpHandler實現(xiàn)圖片驗證碼也可以在一個.ashx文件中實現(xiàn)IHttpHandler,而不是采用這種提前編譯的方式。 Step.1 打開Vs2005,“添加新項”,“一般處理程序”。新建文件后,VS會自動在文件中添加如下的代碼:<%@ WebHandler Language="C#" Class="Handler" %> Step.2 將代碼改寫成如下所示:<%@ WebHandler Language="C#" Class="Handler" %> 需要特別注意的是,Handler類不僅需要實現(xiàn) IHttpHandler接口(這個顯然),為了在這個Handler類中使用SessionState,還需要實現(xiàn)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.(翻譯過來是:指定當(dāng)前Http Handler需要對SessionState值的讀寫訪問權(quán)。這是一個標(biāo)記接口,沒有任何方法)。 而實際上,IRequiresSessionState的接口定義是這樣的: public interface IRequiresSessionState{} 可見,這個接口沒有任何需要實現(xiàn)的方法或?qū)傩?,大家只要記得?strong>如果想在HttpHandler中使用SessionState,必須實現(xiàn)這個接口,實際上也就是在類的標(biāo)頭將這個接口加進(jìn)去。 Step.3 新建一個ImageCode.aspx頁面,在HTML代碼中寫下:<img src="Handler.ashx" alt="圖片驗證碼" /> OK,在瀏覽器中打開ImageCode.aspx,應(yīng)該可以看到如下所示: 利用HttpHandler創(chuàng)建自定義后綴Rss源RSS如今已經(jīng)可以說是隨處可見,而RSS的實現(xiàn)方式,通常是在一個.aspx的CodeBehind文件中寫一個XML文件,然后加載到Response的OutputStream中, Rss源通常是Rss.aspx這種形式的。通過第一章學(xué)到的ISAPI的知識,再結(jié)合本章學(xué)到的關(guān)于HttpHandler的知識,很容易想到:我們可以自定一個以 .rss 作為后綴名的文件來實現(xiàn) Rss 源,比如說Article.rss。現(xiàn)在我們就一步步來實現(xiàn)它: NOTE:關(guān)于RSS的更多內(nèi)容,可以參閱我編譯的 在Web站點中創(chuàng)建和使用RSS源。本文不再解釋Rss是什么,如何創(chuàng)建Rss源,為了文章的獨立性,僅給出創(chuàng)建過程。 Step.1 創(chuàng)建范例數(shù)據(jù)庫Create Table RssSample Step.2 建立站點,在App_Code目錄下建立RssFeedsLib.cs文件。using System; Step.3 創(chuàng)建可以處理 .rss 后綴名的 RssHandler我們在這個 RssFeedsLib命名空間下,再添加一個類,這個類用于處理對 .rss 后綴名文件的Http請求。 public class RSSHandler:IHttpHandler{ Step.4 在Web.config中進(jìn)行配置<httpHandlers>
NOTE:因為這個類和命名空間位于App_Code中,這里就不需要再手動編譯RssFeadsLib.cs然后將編譯好的.dll應(yīng)用程序集放到Bin目錄中了。至于為什么可以這樣,將會在 《Asp.Net 構(gòu)架與安全機制 Part.5 – 頁面生存周期與編譯模型》中解釋。 Step.5 在IIS 對ISAPI進(jìn)行設(shè)置。應(yīng)該還記得在Part.1中如何在IIS中設(shè)置ISAPI來進(jìn)行文件與處理程序映射:
進(jìn)行了這些設(shè)置以后,現(xiàn)在IIS就知道如何去處理對.rss后綴名文件的請求了。 Step.6 測試范例這個時候,隨便打開一個頁面,比如空白的Default.aspx,然后我們在地址欄將文件改為:Article.rss(改成abc.rss也是一樣),敲回車,應(yīng)該可以看到如下的畫面。 IHttpHandlerFactory 概述現(xiàn)在假設(shè)我們有這樣的需求,我們不僅想要處理 .rss 后綴名,還想要能夠處理 .atom后綴名,假設(shè)處理atom的類命名為AtomHandler,那么我們的Web.config該如何設(shè)置呢?我想應(yīng)該是這樣的: <httpHandlers> 如果我們有很多個HttpHandler分別映射不同后綴名的請求,這樣我們的Web.config會變得很冗長,或者,我們只有在程序運行時才能確切地知道使用哪個Handler,這個時候,可以考慮實現(xiàn) IHttpHandlerFactory來完成這一過程。 IHttpHandlerFactory的定義是這樣的: public interface IHttpHandlerFactory{ 可見,需要實現(xiàn)兩個方法,分別是 GetHandler() 和 ReleaseHandler()。
對于上面 .atom 和 .rss 的問題,我們可以這樣來實現(xiàn) IHttpHandlerFactory接口: class HandlerFactory:IHttpHandlerFactory{ 這時,在Web.Config 中<system.web>節(jié)點下進(jìn)行如下設(shè)置即可: <httpHandlers> 但是,這不能簡化IIS中ISAPI的設(shè)置,還是需要手動去對.rss和.atom分別設(shè)置。 總結(jié)在本文中,我們首先討論了aspnet_isapi.dll 如何將對不同后綴名文件的請求分發(fā)給相應(yīng)的處理程序,如何查看Framework默認(rèn)的處理程序Handler。 然后,我們通過三個實例,圖片防盜鏈、圖片驗證碼、處理自定義后綴名請求,詳細(xì)講解了IHttpHandler的實現(xiàn)方法和使用過程。 最后,我向大家概要地介紹了IHttpHandlerFactory接口。 第三回:引言Http 請求處理流程 和 Http Handler 介紹 這兩篇文章里,我們首先了解了Http請求在服務(wù)器端的處理流程,隨后我們知道Http請求最終會由實現(xiàn)了IHttpHandler接口的類進(jìn)行處理(應(yīng)該記得Page類實現(xiàn)了IHttpHandler)。從 Http 請求處理流程 一文的最后的一幅圖中可以看到,在Http請求由IHttpHandler處理之前,它需要通過一系列的Http Module;在請求處理之后,它需要再次通過一系列的Http Module,那么這些Http Module是如何組成的?用來做什么呢?本文將對Http Module作以介紹。 Http Module概述暫時先不考慮我們自己實現(xiàn)Http Module的情況。在.Net中,Http Module 是實現(xiàn)了IHttpModule接口的程序集。IHttpModule 接口本身并沒有什么好大寫特寫的,由它的名字可以看出,它不過是一個普普通通的接口而已。實際上,我們關(guān)心的是實現(xiàn)了這些接口的類,如果我們也編寫代碼實現(xiàn)了這個接口,那么有什么用途。一般來說,我們可以將Asp.Net中的事件分成三個級別,最頂層是 應(yīng)用程序級事件、其次是頁面級事件、最下面是控件級事件,事件的觸發(fā)分別與 應(yīng)用程序周期、頁面周期、控件周期緊密相關(guān)。而 Http Module 的作用是與應(yīng)用程序事件 密切相關(guān)的。 我們通過Http Module在Http請求管道(Pipeline)中注冊期望對應(yīng)用程序事件做出反應(yīng)的方法,在相應(yīng)的事件觸發(fā)的時候(比如說BeginRequest事件,它在應(yīng)用程序收到一個Http請求并即將對其進(jìn)行處理時觸發(fā)),便會調(diào)用Http Module注冊了的方法,實際的工作在這些方法中執(zhí)行。.Net 本身已經(jīng)有很多的Http Module,其中包括 表單驗證Module(FormsAuthenticationModule), Session 狀態(tài)Module(SessionStateModule),輸出緩存Module (OutputCacheModule)等。 注冊 Http Module在注冊我們自己編寫的 Http Module 之前,先來看看Asp.Net中已經(jīng)有的HttpModule。與 Http Handler類似,我們需要打開機器上C:\WINDOWS\Microsoft.NET\Framework\ v2.0.50727\CONFIG 目錄下的 web.config 文件。找到 <httpModules/> 結(jié)點,應(yīng)該可以看到下面的內(nèi)容: <httpModules> 我們先從結(jié)點上看,type屬性與上一節(jié)所說的http handler結(jié)點的type屬性類似,都代表了相應(yīng)的程序集。但是,與http handler 不同,module只提供了一個name屬性,沒有諸如 path這樣指定某一特定(或者用通配符 * 代表某一種類)文件的處理程序。這是與Module的特點相關(guān)的,我們知道 module 是響應(yīng)應(yīng)用程序周期中觸發(fā)的事件,對于所有提交到aspnet_isapi.dll的請求都一樣,即便請求只是像類似http://www./images/logo.gif 這樣獲取一張圖片而已(對ISAPI進(jìn)行過設(shè)置以后,默認(rèn)aspnet_isapi.dll不接手圖片文件)。 與Http handler類似,在這冊我們自己的http module 時,假設(shè)類名為ModuleDemo,位于myNameSpace命名空間下,程序集名稱為myDll,我們只需將myDll.dll拷貝到Bin目錄下,并在站點的 web.config 文件 system.web 結(jié)點下創(chuàng)建 httpModules 結(jié)點: <system.web> type屬性由分號“,”分為兩部分,前面是命名空間及類名,也就是類型名;后面是程序集名。如果我們將代碼創(chuàng)建在App_Code目錄中,則不需要再指定程序集名。 name屬性由我們自己命名,不一定與類名相同,此處我將它命名為“CustomModuleName”。我們可以通過應(yīng)用程序(HttpApplication)的Modules屬性獲取HttpModuleCollection集合,然后通過name屬性,進(jìn)一步獲取HttpModule對象。 通過name屬性,我們還可以在global.asax中文件中編寫自定義HttpModule暴露出的事件的處理程序,它采用的格式是:void ModuleName_EventName(object sender, EventArgs e)。我們將在后面做更詳細(xì)介紹。 Asp.Net 內(nèi)置的 Http Modules下面這張表格列出了C:\WINDOWS\Microsoft.NET\Framework\ v2.0.50727\CONFIG下的Web.Config中的 Asp.Net 內(nèi)置的Http Modules 及其主要作用。
我們將在后面用編程的方式來查看它。 IHttpModule接口看了這么多理論知識,本節(jié)將開始動手寫點程序,實現(xiàn)自己的Http Module。我們首先需要看下IHttpModule 接口,它包括下面兩個方法: public void Init(HttpApplication context); Init():這個方法接受一個HttpApplication對象,HttpApplication代表了當(dāng)前的應(yīng)用程序,我們需要在這個方法內(nèi)注冊 HttpApplication對象暴露給客戶端的事件。可見,這個方法僅僅是用來對事件進(jìn)行注冊,而實際的事件處理程序,需要我們另外寫方法。 整個過程很好理解:
NOTE:如果你不了解事件注冊等相關(guān)內(nèi)容,請參閱 C#中的委托與事件 一文。 Dispose():它可以在進(jìn)行垃圾回收之前進(jìn)行一些清理工作。 綜上所述:實現(xiàn)一個 IHttpModule 的模板一般是這樣的: public class ModuleDemo:IHttpModule 通過Http Module向Http請求輸出流中寫入文字本例中,我們僅用BeginRequest事件和 EndRequest 事件對 Http Module 的使用作以說明。我們通過這個范例,了解 Http Module 基本的使用方法。 首先,請創(chuàng)建一個新的站點,在App_Code目錄中添加類文件: ModuleDemo.cs: public class ModuleDemo:IHttpModule 上面的代碼很簡單,它注冊了 HttpApplication實例的 BeginRequest 事件 和 EndRequest事件,事件處理方法的作用僅僅是在http請求開始和結(jié)束的時候,給http請求的輸入流中分別寫入不同的內(nèi)容。 接下來在 Web.config 的 System.web 結(jié)點中寫入以下內(nèi)容: <system.web> 然后,打開建立站點時自動創(chuàng)建的 Default.aspx文件,在里面打幾個字,為了做區(qū)分,我輸入的是:位于.aspx頁面上的文字。然后,我們在瀏覽器中打開它,應(yīng)該會看到像這樣: 然后我們再新建一個 Default2.aspx,在瀏覽器中瀏覽,可以看到,兩個頁面的效果相同。這說明對于不同的兩個文件,http Module都起了作用,可見它確實是位于應(yīng)用程序級,而非頁面級。 現(xiàn)在,我們再打開站點中的一張圖片文件,發(fā)現(xiàn)顯示出的是一個紅叉叉,為什呢?因為Http Module 針對是http 請求,而不是某個或某一類文件,所以當(dāng)請求一張圖片的時候,我們編寫的http Module依然會起作用,將文字插入到二進(jìn)制圖片中,破壞了文件格式,自然只能顯示紅叉叉了。 NOTE:如果你發(fā)現(xiàn)你的圖片顯示正常,請不要驚訝,事情是這樣的:回想一下第一節(jié)我們討論到的,對于圖片文件,由IIS直接處理,并不會交由aspnet_isapi.dll,所以,Module無法捕獲對于圖片類型文件的請求。解決方法就是在IIS中進(jìn)行設(shè)置一下。 遍歷Http Module集合現(xiàn)在,我們通過遍歷 HttpModuleCollection 集合來查看注冊給應(yīng)用程序的所有 Http Module 的名稱。 新建一個文件 RegisteredModules.aspx,在代碼后置文件中添加如下方法: private string ShowModules() { 然后在Page_Load方法中輸出一下: protected void Page_Load(object sender, EventArgs e) 我們應(yīng)該可以看到下面這樣的畫面: 與之前列出的那張表格比較一下,可以看出是幾乎完全一致的(多了一個DefaultAuthentication)。另外注意上圖的倒數(shù)第四行,那不是我們自己定義的Module么?name為MyModule,類型為ModuleDemo。 Global.asax文件與 Http Module早在asp時代,大家就知道這個文件了。它主要用于放置對于 應(yīng)用程序事件或者 Session事件的響應(yīng)程序。大家熟悉的有Application_Start、Application_End、Session_Start、Session_End 等。 在asp.net中,Glabal不僅可以注冊應(yīng)用程序和Session事件,還可以注冊Http Module暴露出的事件;不僅可以注冊系統(tǒng)Module的事件,也可以注冊我們自己義的Module暴露出的事件。在具體介紹之前,這里需要首先注意兩點:
好了,我們現(xiàn)在修改之前 ModuleDemo 范例程序,給它像下面這樣給它添加一個事件(為了使程序簡潔一些,我做了簡化): public class ModuleDemo : IHttpModule { 接下來,我們在站點中創(chuàng)建一個 Global.asax 文件,在里面添加如下代碼,注意到格式是:void 模塊名_事件名(object sender, EventArgs e)。 void MyModule_ExposedEvent(object sender, EventArgs e) 現(xiàn)在,我們打開之前的頁面,應(yīng)該可以見到這樣,可見,我們成功的將 Glabal.asax文件與我們自己定義的Http Module所暴露出的事件 ExposedEvent 聯(lián)系到了一起: 總結(jié)本文簡單地介紹了什么是Http Module。我們首先了解了Http Module的作用,然后查看了Asp.Net 內(nèi)置的Module,接著我們介紹了IHttpModule接口,并通過了一個簡單的范例實現(xiàn)了此接口,最后我們討論了 Http Module與 Global.asax 文件的聯(lián)系。 |
|