|
|
如何使用微軟提供的ASP.NET來對(duì)動(dòng)態(tài)產(chǎn)生的URL地址進(jìn)行網(wǎng)址重寫。網(wǎng)址重寫是實(shí)現(xiàn)一種截取網(wǎng)址請(qǐng)求并將其進(jìn)行處理后重新指向到一個(gè)指定的網(wǎng)址的過程。作者本人在對(duì)各種實(shí)現(xiàn)網(wǎng)址重寫的技術(shù)進(jìn)行研究和探討后得出的經(jīng)驗(yàn)和方法，希望能對(duì)您有所幫助。
1.2. 內(nèi)容簡介
稍微花點(diǎn)時(shí)間看類似這樣的地址：http://www.XXX.com/EmployeeInfo.ASPx?ID=459&type=summary ，也許你會(huì)出于某種目的把大量的頁面文件從一個(gè)目錄甚至一個(gè)網(wǎng)站轉(zhuǎn)移到其他地方，而許多訪問者出于個(gè)人興趣或者研究目的之前就已經(jīng)將原有網(wǎng)址收藏了起來，如果這時(shí)他從收藏夾打開該頁面的時(shí)候發(fā)現(xiàn)這已經(jīng)是壞鏈了。本文旨在介紹如何使用網(wǎng)址重寫將那些“難看”的網(wǎng)址轉(zhuǎn)換成比較有實(shí)際意義的網(wǎng)址，使其便于記憶。例如將http://www.XXX.com/EmployeeInfo.ASPx?ID=459&type=summary轉(zhuǎn)換成如下地址：http://www.XXX.com/EmployeeInfo/459/summary.html 。我們甚至發(fā)現(xiàn)網(wǎng)址重寫技術(shù)可以解決令人頭疼的404錯(cuò)誤，或者說它可以創(chuàng)建一個(gè)智能化的404錯(cuò)誤解決方案。
網(wǎng)址重寫是實(shí)現(xiàn)一種截取網(wǎng)址請(qǐng)求并將其進(jìn)行處理后重新指向到一個(gè)指定的網(wǎng)址的過程。在網(wǎng)址重寫執(zhí)行的期間，相應(yīng)處理程序處理被請(qǐng)求的網(wǎng)址，從中提取出相關(guān)的值，然后重新指向一個(gè)新的指定地址。例如：由于一次網(wǎng)站目錄調(diào)整，原有的 /people/ 子目錄下的所有網(wǎng)頁全部移動(dòng)到/info/employees/目錄，原訪問者從收藏夾或者其他什么地方點(diǎn)擊鏈接發(fā)出訪問/people/目錄下的文件的請(qǐng)求時(shí)，你肯定希望他還是能通過原有地址看到和原來相同的頁面，但實(shí)際上看到的卻是網(wǎng)址重寫指向的新目錄下的相應(yīng)文件。
在老版本ASP中，使用網(wǎng)址重寫技術(shù)的途徑很少，要么寫一個(gè)ISAPI過濾器，要么購買第三方廠商提供的網(wǎng)址重寫組件，然而在微軟提供的ASP.NET下你可以通過多種方法很簡單地開發(fā)出自己的網(wǎng)址重寫軟件，以滿足自己各種不同的需要。本文將和你一起討論這門針對(duì)ASP.NET開發(fā)人員的實(shí)現(xiàn)網(wǎng)址重寫的技術(shù)，然后舉一些網(wǎng)址重寫實(shí)際應(yīng)用的例子。在我們深入探討網(wǎng)址重寫技術(shù)的細(xì)節(jié)之前，我們先看一下日常使用網(wǎng)址重寫技術(shù)實(shí)現(xiàn)的場景。
1.3. 網(wǎng)址重寫的一般用途
創(chuàng)建一個(gè)數(shù)據(jù)操作的ASP.NET程序最常見的就是一個(gè)ASPx頁面后面帶上一些查詢參數(shù)集合。例如在設(shè)計(jì)一個(gè)電子商務(wù)網(wǎng)站的時(shí)候，假定你設(shè)計(jì)了一項(xiàng)功能允許用戶瀏覽待售的商品，為了更加方便操作，你設(shè)計(jì)了一個(gè)頁面Category.ASPx將商品按照給定的分類顯示，那么該分類下的商品顯示頁面上應(yīng)該在頁面文件對(duì)應(yīng)網(wǎng)址后面加上了一個(gè)商品分類的查詢參數(shù)，例如用戶要查詢待售的“裝飾品”，在數(shù)據(jù)庫中所有的裝飾品數(shù)據(jù)對(duì)應(yīng)的分類編號(hào)CategoryID的值為5，那么用戶會(huì)訪問如下網(wǎng)址：http://www.XXX.com/Category.ASPx?CategoryID=5。
創(chuàng)建一個(gè)包含類似這樣網(wǎng)址的網(wǎng)站最終有兩種結(jié)果，首先從最終用戶的角度來觀察，http://://www.XXX.com/Category.ASPx?CategoryID=5 這個(gè)網(wǎng)址有些雜亂，可行性分析專家Jakob Neilson建議選擇網(wǎng)址顯示方式時(shí)候考慮如下要求：
● 是否簡短
● 是否易于輸入
● 是否將站點(diǎn)結(jié)構(gòu)形象化
● 是否具有隱蔽性，也就是讓用戶通過一個(gè)虛擬的看似有意義的導(dǎo)航地址訪問指向該地址
我想還應(yīng)該在上述列表中再增加一條：是否便于記憶。http://www.XXX.com/Category.ASPx?CategoryID=5 這個(gè)地址沒有一個(gè)地方符合Neilson標(biāo)準(zhǔn)的任何一條，也不便于記憶。當(dāng)然，對(duì)于有經(jīng)驗(yàn)的網(wǎng)絡(luò)開發(fā)專家來說，他們很熟悉這種鍵值對(duì)構(gòu)成的查詢參數(shù)結(jié)構(gòu)體系，然而對(duì)于普通用戶來說輸入這些帶有參數(shù)的網(wǎng)址實(shí)在是太麻煩了。
一種較好的方法就是使用一種比較直觀且容易記憶的方式來將網(wǎng)址表示為：http://www.XXX.com/products/Widgets 乍一看很容易就會(huì)推斷這個(gè)網(wǎng)址所對(duì)應(yīng)的內(nèi)容極有可能會(huì)是顯示裝飾品（Widgets）信息，這個(gè)網(wǎng)址就變得更加容易記憶和傳播！然后我告訴我的同事：“請(qǐng)查看這個(gè)網(wǎng)址：http://://www.XXX.com/products/widgets ”不用我說第二遍，她可能一次就把地址敲到瀏覽器上了。很快就瀏覽器上就列出了裝飾品（Widgets）的內(nèi)容。這里“隱蔽性”表示：用戶可以自行變更網(wǎng)址的結(jié)尾，例如輸入：http://www.XXX.com/products 就能看到全部分類相關(guān)的商品列表或者列出所有相關(guān)商品分類目錄列表。
注：用上述簡單的變更網(wǎng)址內(nèi)容的方法來構(gòu)思一下如今的比較流行的Blog網(wǎng)站生成的網(wǎng)址。例如：要查詢2004年1月28日所發(fā)的帖子，只需輸入 http://someblog.com/2004/01/28 即可，如果將網(wǎng)址裁減為 http://someblog.com/2004/01 則顯示 2004年1月份的帖子 ，同樣將月份裁減掉得到 http://someblog.com/2004 則顯示出2004年全年所發(fā)的帖子。
網(wǎng)址重寫技術(shù)除了用于將復(fù)雜的網(wǎng)址簡單化之外，它還能用于處理因網(wǎng)站目錄調(diào)整或者其他原因?qū)е庐a(chǎn)生大量的無效鏈接和過期書簽。
1.4. 當(dāng)一個(gè)Web請(qǐng)求傳送到IIS會(huì)發(fā)生什么？
在探討如何實(shí)現(xiàn)網(wǎng)址重寫這項(xiàng)技術(shù)之前，很有必要了解一下IIS是處理所接收的Web請(qǐng)求的機(jī)制。當(dāng)一個(gè)Web請(qǐng)求到達(dá)IIS Web服務(wù)器時(shí)，IIS會(huì)根據(jù)所請(qǐng)求的文件后綴名來決定如何處理該請(qǐng)求，IIS可以處理諸如HTML頁面、圖片、靜態(tài)內(nèi)容，或者將請(qǐng)求轉(zhuǎn)發(fā)給ISAPI應(yīng)用程序，由該ISAPI應(yīng)用程序處理后生成HTML靜態(tài)內(nèi)容返回給IIS，最后由IIS將請(qǐng)求結(jié)果發(fā)送回給客戶端。（一個(gè)ISAPI應(yīng)用程序就是一套編譯好能隨時(shí)在后臺(tái)運(yùn)行的類庫，它的任務(wù)就是根據(jù)請(qǐng)求生成相關(guān)的內(nèi)容。）
例如：如果IIS接收到一個(gè)對(duì)Info.ASP的請(qǐng)求，它會(huì)將該請(qǐng)求轉(zhuǎn)交給ASP.dll來處理，該ISAPI應(yīng)用程序調(diào)出并執(zhí)行所請(qǐng)求的ASP頁面，然后把生成的HTML代碼返回給IIS，IIS最后把內(nèi)容發(fā)送回請(qǐng)求客戶端。對(duì)于ASP.NET頁面，IIS則將請(qǐng)求轉(zhuǎn)交給名為 ASPNET_isapi.dll的ISAPI應(yīng)用程序來處理，該ISAPI應(yīng)用程序調(diào)用托管的ASP.NET工作進(jìn)程來處理該請(qǐng)求，并將生成的HTML 代碼返回給請(qǐng)求客戶端。你可以自定義IIS，將某一類擴(kuò)展名映射到指定的ISAPI應(yīng)用程序。
關(guān)于對(duì)IIS如何管理所接收的請(qǐng)求的詳細(xì)探討有些超出本文內(nèi)容，想了解的更詳細(xì)的話可以參考Michele Leroux Bustamante的著作Inside IIS and ASP.NET(深入研究IIS與ASP.NET)，重要的是要了解ASP.NET引擎只負(fù)責(zé)處理對(duì)擴(kuò)展名已經(jīng)被正確配置映射到ASPNET_isapi.dll的網(wǎng)絡(luò)請(qǐng)求。
1.5. 用ISAPI過濾器來分析請(qǐng)求
除了將請(qǐng)求的文件擴(kuò)展名映射到相應(yīng)的ISAPI應(yīng)用程序外，IIS還執(zhí)行一些其他工作。例如IIS還主動(dòng)對(duì)發(fā)出請(qǐng)求的客戶端用戶進(jìn)行授權(quán)，并判斷已授權(quán)用戶是否對(duì)其請(qǐng)求的文件擁有訪問權(quán)限，在一個(gè)請(qǐng)求過程的全部生命期內(nèi)，IIS的處理經(jīng)歷了幾個(gè)階段，在每一個(gè)階段IIS都生成一個(gè)事件，而該事件可以被 ISAPI過濾器實(shí)時(shí)操控的。
如同ISAPI應(yīng)用程序一樣，ISAPI過濾器也是一塊塊安裝在Web服務(wù)器上的非托管代碼。ISAPI應(yīng)用程序用于對(duì)所接收的特定文件類型做出響應(yīng)，而 ISAPI過濾器含有對(duì)IIS生成的事件做出響應(yīng)的代碼（contain Code），甚至可以編輯進(jìn)出的數(shù)據(jù)。ISAPI也含有眾多應(yīng)用程序，包括：
● 權(quán)限控制與授權(quán)（Authentication and Authorization）
● 日志記錄與監(jiān)視（Logging and Monitoring）
● HTTP內(nèi)容壓縮（HTTP Compression）
● 網(wǎng)址重寫（URL Rewriting）
本文所探討的用ASP.NET實(shí)現(xiàn)的網(wǎng)址重寫技術(shù)就是基于ISAPI過濾器用于網(wǎng)址重寫的技術(shù)內(nèi)容，然而我們?nèi)匀灰懻撘幌戮烤故鞘褂肐SAPI過濾器還是使用ASP.NET應(yīng)用程序提供的技術(shù)來實(shí)現(xiàn)網(wǎng)址重寫技術(shù)。
1.6. 當(dāng)一個(gè)請(qǐng)求傳入ASP.NET引擎的時(shí)候會(huì)發(fā)生什么？
ASP.NET問世之前，在IIS Web服務(wù)器上的網(wǎng)址重寫功能需要通過ISAPI過濾器來實(shí)現(xiàn)，自從這個(gè)家伙問世后我們就能通過ASP.NET來實(shí)現(xiàn)URL重寫了，因?yàn)?a href=/itjie/ASPjishu/ target=_blank class=infotextkey>ASP.NET的解釋引擎與IIS有極大的相似之處，產(chǎn)生這些相似性主要是因?yàn)?a href=/itjie/ASPjishu/ target=_blank class=infotextkey>ASP.NET：
● 在處理接收的請(qǐng)求的生命期內(nèi)也會(huì)產(chǎn)生事件；
● 允許任意數(shù)量的HttpModule操控產(chǎn)生的事件，這與IIS中的ISAPI過濾器類似；
● 將請(qǐng)求的資源委托給HttpHandler處理，這與IIS中的ISAPI應(yīng)用程序類似。
和IIS一樣，在一個(gè)請(qǐng)求的整個(gè)生命期內(nèi)，ASP.NET對(duì)該請(qǐng)求的處理狀態(tài)發(fā)出的狀態(tài)改變信號(hào)引發(fā)相應(yīng)的事件。例如：BeginRequest事件在 ASP.NET開始響應(yīng)客戶端請(qǐng)求之始引發(fā)；AuthenticateRequest事件在ASP.NET確立用戶身份后引發(fā)，當(dāng)然還有諸如 AuthorizeRequest，ResolveRequestCache和EndRequest等其它很多事件，這些都是 System.Web.HttpApplication類下的事件，更多信息請(qǐng)參考技術(shù)文檔中的類HttpApplication概要（HttpApplication Class Overview）。
如上所述，可以創(chuàng)建ISAPI過濾器并用于相應(yīng)IIS引發(fā)的事件，同理，ASP.NET也提供了HttpModule用于響應(yīng)ASP.NET引擎引發(fā)的事件，一個(gè)ASP.NET應(yīng)用程序通過配置可以擁有多個(gè)HttpModule。ASP.NET引擎每處理一個(gè)請(qǐng)求，便初始化一個(gè)相應(yīng)配置好的 HttpModule，并允許它針對(duì)請(qǐng)求處理期間引發(fā)的事件生成相應(yīng)的事件委托。事實(shí)上ASP.NET引擎處理每一個(gè)請(qǐng)求調(diào)用大量的事件委托。 FormsAuthenticationModule就是眾多內(nèi)嵌HttpModule中的一個(gè)，它首先檢查是否使用表單授權(quán)，如果是的話，它將檢查用戶是否已授權(quán)，如果沒有授權(quán)則自動(dòng)把用戶重定向到指定的登錄頁面。
回憶在IIS中，一項(xiàng)請(qǐng)求最后被轉(zhuǎn)交給一個(gè)ISAPI應(yīng)用程序處理，該應(yīng)用程序針對(duì)每一項(xiàng)請(qǐng)求進(jìn)行處理并返回相應(yīng)的數(shù)據(jù)。例如，客戶端發(fā)出一個(gè)訪問經(jīng)典 ASP頁面的請(qǐng)求，IIS將該請(qǐng)求轉(zhuǎn)交給ASP.dll程序處理，ASP.dll針對(duì)該請(qǐng)求執(zhí)行ASP頁面內(nèi)容，并返回HTML編碼。ASP.NET也使用了類似的手法，ASP.NET引擎在將這些HttpModule初始化后，判斷并決定調(diào)用相應(yīng)的HttpModule來處理該請(qǐng)求。
所有通過ASP.NET引擎解析的請(qǐng)求最終被送交一個(gè)HttpHandler或者HttpHandlerFactory（一個(gè)HttpHandler只是簡單地返回一個(gè)用于處理該請(qǐng)求的HttpHandler的實(shí)例。）最終的委托呈現(xiàn)并響應(yīng)所請(qǐng)求的HTML編碼，并發(fā)送回IIS，IIS則將HTML返回給請(qǐng)求客戶端。
ASP.NET包含許多HttpHandler，例如，PageHandlerFactory是用于呈現(xiàn)ASP.NET頁面內(nèi)容， WebServiceHandlerFactory用于呈現(xiàn)ASP.NET Web服務(wù)的SOAP數(shù)據(jù)包，TraceHandler用于將ASP.NET請(qǐng)求資源的HTML標(biāo)記寫入trace.axd。
ASP.NET資源的請(qǐng)求所經(jīng)過的處理流程：首先，IIS接收到該請(qǐng)求并將其轉(zhuǎn)交給ASPNET_isapi.dll。其次，ASP.NET引擎將一些 HttpModule初始化。最后，最終的HttpHandler被調(diào)用，生成相應(yīng)的標(biāo)記語言，并將其返回給IIS，最終返回到請(qǐng)求客戶端。
AspNet技術(shù)：Asp.Net 重定向必須要知道的一些資料，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
