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