1.2. 內容簡介
稍微花點時間看一看你做的網站裡頭的URL地址，你看到類似這樣的地址嗎http://yoursite.com/info/dispEmployeeInfo.aspx?EmpID=459-099&type=summary ？也許你會出於某種目的把大量的頁面文件從一個目錄甚至一個網站轉移到其他地方，而許多訪問者出於個人興趣或者研究目的之前就已經將原有網址收藏了起來， 如果這時他從收藏夾打開該頁面的時候發現這已經是壞鏈了。本文旨在介紹如何使用網址重寫將那些“難看”的網址轉換成比較有實際意義的網址，使其便於記憶。例如將http://yoursite.com/info/dispEmployeeInfo.aspx?EmpID=459-099&type=summary轉換成如下地址：http://yoursite.com/ dispEmployeeInfo/459-099/summary.html 。我們甚至發現網址重寫技術可以解決令人頭疼的404錯誤，或者說它可以創建一個智能化的404錯誤解決方案。
如上所述，網址重寫是實現一種截取網址請求並將其進行處理後重新指向到一個指定的網址的過程。在網址重寫執行的期間，相應處理程序處理被請求的網址，從中提取出相關的值，然後重新指向一個新的指定地址。例如：由於一次網站目錄調整，原有的 /people/ 子目錄下的所有網頁全部移動到/info/employees/目錄，原訪問者從收藏夾或者其他什麼地方點擊鏈接發出訪問/people/目錄下的文件的請求時，你肯定希望他還是能通過原有地址看到和原來相同的頁面，但實際上看到的卻是網址重寫指向的新目錄下的相應文件。
在老版本ASP中，使用網址重寫技術的途徑很少，要麼寫一個ISAPI過濾器，要麼購買第三方廠商提供的網址重寫組件，然而在微軟提供的ASP.NET下你可以通過多種方法很簡單地開發出自己的網址重寫軟件，以滿足自己各種不同的需要。本文將和你一起討論這門針對ASP.NET開發人員的實現網址重寫的技術，然後舉一些網址重寫實際應用的例子。在我們深入探討網址重寫技術的細節之前，我們先看一下日常使用網址重寫技術實現的場景。
1.3. 網址重寫的一般用途
創建一個數據操作的ASP.NET程序最常見的就是一個aspx頁面後面帶上一些查詢參數集合。例如在設計一個電子商務網站的時候，假定你設計了一項功能允許用戶浏覽待售的商品，為了更加方便操作，你設計了一個頁面displayCategory.aspx將商品按照給定的分類顯示，那麼該分類下的商品顯示頁面上應該在頁面文件對應網址後面加上了一個商品分類的查詢參數，例如用戶要查詢待售的“裝飾品”，在數據庫中所有的裝飾品數據對應的分類編號CategoryID的值為5，那麼用戶會訪問如下網址：http://yoursite.com/displayCategory.aspx?CategoryID=5。
創建一個包含類似這樣網址的網站最終有兩種結果，首先從最終用戶的角度來觀察，http://yoursite.com/displayCategory.aspx?CategoryID=5 這個網址有些雜亂，可行性分析專家Jakob Neilson（主頁：http://useit.com/） 建議選擇網址顯示方式時候考慮如下要求（參考網址：http://www.useit.com/alertbox/990321.html）：
● 是否簡短
● 是否易於輸入
● 是否將站點結構形象化
● 是否具有隱蔽性，也就是讓用戶通過一個虛擬的看似有意義的導航地址訪問指向該地址
我想還應該在上述列表中再增加一條：是否便於記憶。http://yoursite.com/displayCategory.aspx?CategoryID=5 這個地址沒有一個地方符合Neilson標准的任何一條，也不便於記憶。當然，對於有經驗的網絡開發專家來說，他們很熟悉這種鍵值對構成的查詢參數結構體系，然而對於普通用戶來說輸入這些帶有參數的網址實在是太麻煩了。
一種較好的方法就是使用一種比較直觀且容易記憶的方式來將網址表示為：http://yoursite.com/products/Widgets 乍一看很容易就會推斷這個網址所對應的內容極有可能會是顯示裝飾品（Widgets）信息，這個網址就變得更加容易記憶和傳播！然後我告訴我的同事：“請查看這個網址：http://yoursite.com/products/widgets ”不用我說第二遍，她可能一次就把地址敲到浏覽器上了（你也可以在亞馬遜（Amazon.com）的網站上這樣嘗試一下）。很快就浏覽器上就列出了裝飾品（Widgets）的內容。這裡“隱蔽性”表示：用戶可以自行變更網址的結尾，例如輸入：http://yoursite.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管理工具中的應用程序配置對話框。
圖一．已配置的文件擴展名映射
關於對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，最終返回到請求客戶端。
圖二．IIS和ASP.NET對請求的處理過程
1.7. 創建並注冊自定義HttpModule和HttpHandler
創建自定義HttpModule的工作相對較簡單，它包括一個實現當前接口的托管類，HttpModule必須實現System.Web.IHttpModule接口，同樣HttpHandler和HttpHandlerFactory必須分別實現System.Web.IHttpHandler接口和System.Web.IhttpHandlerFactory接口。有關創建HttpHandler和HttpModule的細節已經超出本書范圍，要了解更多詳情請參閱Mansoor Ahmed Siddiqui的文章《HttpHandlers and HTTP modules in ASP.NET》（ASP.NET中的HttpHandler和HttpModule）。
一旦HttpModule和HttpHandler被創建後，必須向Web應用程序注冊。如果要向整個Web服務器HttpModule和HttpHandler只需簡單的寫入machine.config文件；如果是由指定的Web應用程序調用則需在該程序的web.config配置文件中添加幾行XML標記。
例如，要向指定的Web應用程序注冊HttpModule和HttpHandler，只需向該Web應程序的web.config配置文件中configuration\System.Web節中添加下列幾行：
<HttpModules> <add type="type" name="name" /></HttpModules>
其中type屬性為HttpModule的標識號和類庫名稱，name屬性則為該模塊取一個較為友好的名稱方便在Global.asax調用。
HttpHandler和HttpHandlerFactory則是在web.config文件中configuration\System.Web節中添加<httpHandler>標記，例如：
<httpHandlers> <add verb="verb" path="path" type="type" /></HttpModules>
回憶上文，ASP.NET對每一個接收到的請求指派相應的HttpHandler來處理並呈現相應內容，該指派決定於所接收請求的verb和path的內容，verb為HTTP請求的類型：GET或者POST，path則為請求的文件的路徑和文件名。如果我們打算用一個HttpHandler來處理所有GET類型和POST類型的並且文件擴展名為.scott的內容，可以在web.config相應配置節中加入下列標記：
<httpHandlers> <add varb="*" path=".scott" type="type" /></httpHandlers>
其中type是我們定義的HttpHandler的類型。
注意：在注冊HttpHandler的時候必須注意HttpHandler所使用的文件擴展名必須已經在IIS中做指向ASP.NET引擎的映射，在上面.scott擴展名的例子中，如果我們所使用的.scott擴展名如果沒有在IIS中做指向ASP.NET引擎的映射的話，假定對foo.scott文件發出請求，該請求將導致IIS將foo.scott文件內容直接呈現給客戶端，為了能夠讓HttpHandler處理該請求，必須將.scott擴展名在IIS中做指向ASP.NET引擎的映射，之後IIS才能正確地將.scott的請求轉交給相應的HttpHandler。
有關HttpModule和HttpHandler更詳細的內容請參閱MSDN中<HttpModules>節和<httpHandlers>節的文檔信息。
<HttpModules>文檔參考；
<httpHandlers>文檔參考。
1.8. 實現網址重寫
網址重寫技術不但可以在IIS Web服務器一級通過ISAPI過濾器實現，而且還可以在ASP.NET一級通過HttpModule或者HttpHandler實現。本文主要關注在ASP.NET一級實現網址重寫技術，所以此時不必關注在ISAPI應用程序中實現網址重寫的技術細節，而且有很多第三方廠商提供的ISAPI過濾器，比如
Helicon的ISAPI Rewrite；
QwerkSoft的IIS Rewrite；Port80的PageXChanger；
等等。
1.9. 構建網址重寫引擎
在ASP.NET中實現網址重寫很簡單，只需調用System.Web.HttpContext類的RewritePath()方法即可。HttpContext類中包含有關於特定HTTP請求的HTTP規范信息。ASP.NET引擎每接收到一個特定請求後便針對該請求創建一個特定的實例，這個類包含一些屬性諸如：Request和Response屬性，分別提供對請求和響應的訪問；Application和Session屬性提供對Application變量和Session變量的訪問；User屬性提供對已授權用戶信息的訪問。
在微軟.NET Framework 1.0版本中，RewritePath()方法接收一個新路徑的簡單字符串，在其內部HttpContext類的RewritePath(string)方法內在地更新Request對象的路徑和查詢參數。除了RewritePath(string)方法之外，.NET Framework 1.1版還提供了另外一些重載版本，其中一個重載版本接收三個輸入字符串參數，這種交替的重載形式不僅僅只是設置Request對象的路徑和查詢參數這些屬性，而是設置更深層的成員變量，這些成員變量用於為PhysicalPath、PathInfo、FilePath屬性計算Request對象值。
為了實現ASP.NET中的網址重寫，我們需要創建一個HttpHandler和HttpModule用於：
根據請求的路徑決定所需要重寫的路徑；
重寫路徑，如果需要的話可以調用RewritePath方法；
以前文所構建的那個站點為例，可以通過/info/employee.aspx?empID=EmployeeID來訪問每一個雇員的信息。為了使這個網址更加地具有“隱蔽性”，我們可能會使用更加容易理解的訪問方式如：/people/雇員名.aspx。這裡就有了一個網址重寫的案例：當接收到對/people/ScottMitchell.aspx的請求的時候，我們就得使用網址重寫使得對該頁面的請求被重寫指向到先前使用的/info/employee?EmpID=1001地址。
1.10. 使用HttpModule來調用網址重寫
在ASP.NET一級來執行網址重寫，既可以使用HttpHandler，也可以使用HttpModule。當使用HttpModule的時候，必須決定如果該網址需要被重寫的話，究竟應該在整個請求的生命周期期間的那一個點來使用。乍一看著有些武斷，但是這個決定以重大而且微妙的方式影響到你的應用程序。之所以作出對網址重寫點的選擇是因為內嵌的ASP.NET HttpModule使用Request對象的屬性值來完成自己的工作（回憶一下重寫路徑對Request對象的屬性值的改變），這些內嵌HttpModule和相應事件的密切關系列舉如下：
HttpModule
事件
簡介
FormsAuthenticationModule
AuthenticateRequest
判斷用戶是否已通過表單授權方式獲取授權，如果沒有的話則將用戶重定向到指定的登錄頁面
FileAuthorizationModule
AuthorizeRequest
當使用Windows授權方式的時候，該HttpModule判斷並確定該Microsoft Windows帳戶是否對其請求的資源擁有足夠的權限
UrlAuthorizationModule
AuthorizeRequest
檢查並確認請求者是否對所訪問的網址擁有權限。該Url授權可以在web.config文件的<authorization>和<location>元素中配置
回想一下BeginRequest事件在AuthenticateRequest事件之前引發，而AuthenticateRequest事件又在AuthorizeRequest事件之前引發。
實現網址重寫的一個較為安全的場合就是把它放在在BeginRequest事件中執行，這意味著如果要執行網址重寫的話，在眾多內嵌HttpModule運行的時候他已經完成了。這種途徑的最終用途淋漓盡致地體現在表單驗證上。當用戶訪問受限資源的時候，如果之前使用了表單驗證，他會自動被重定向到指定的登錄頁面，在成功登錄之後，用戶被重定向回先前試圖訪問的受限制頁面。
如果把網址重寫放在BeginRequest事件或者AuthenticateRequest事件中，在登錄頁面上執行提交後，該頁面會將用戶重定向到網址重寫指定的頁面。假定當用戶在浏覽器上敲入/people/ScottMitchell.aspx地址，該地址是要被重定向到/info/employee.aspx?EmpID=1001的，如果該Web應用程序設定使用表單驗證，當用戶開始訪問/people/ScottMitchell.aspx的時候，該網址將重寫指向/info/employee.aspx?EmpID=1001，接著ForumAuthenticationModule啟動，如果需要的話將用戶重定向到登錄頁面，用戶登錄後重定向到的頁面將是/info/employee.aspx?EmpID=1001，這也是自從FormAuthenticationModule啟動運行時所發出請求的頁面。
同上類似，當把網址重寫放在BeginRequest事件或者AuthenticateRequest事件中運行的時候，UrlAuthenticationModule也發現了網址重寫指向的網址，這意味著如果在該應用程序的web.config文件中<location>節為特定的網址配置特定的授權地址的話，你得引用重寫所指向的網址。
為了解決這個微妙的問題，一個可能就是把網址重寫放在AuthorizeRequest事件中運行，但是在使用這種方法解決URL授權和表單授權的異常時又引入了一個新的缺陷：文件授權會失效。當使用Windows驗證的時候，FileAuthorizationModule檢查並驗證已通過驗證的用戶是否擁有足夠的權限訪問特定的ASP.NET頁面。
假定有一群用戶並沒有Windows級別的訪問權限訪問C:\inetpub\wwwroot\info\employee.aspx，當這些用戶試圖訪問/info/employee.aspx?EmpID=1001的時候，他們會得到未授權的錯誤，如果我們把網址重寫放到AuthenticateRequest事件中運行，當FileAuthorizationModule驗證該安全性設置的時候，他仍任人為被請求的文件是/people/ScottMitchell.aspx，而這時該網址已經被重寫了，因此FileAuthorizationModule會直接放行，讓用戶看到了網址重寫指向的內容：/info/employee.aspx?Empid=1001。
那麼什麼時候在HttpModule調用網址重寫合適呢？他決定於所使用的驗證方式，當然如果不使用驗證方式的話，那麼無論是在BeginRequest事件、AuthenticateRequest事件還是AuthorizeRequest事件中調用網址重寫沒有多大區別，如果使用表單驗證方式並且不使用Windows驗證方式的話，把網址重寫放入AuthorizeRequest事件委托中調用既可，如果使用Windows驗證方式的話，把這項功能放入BeginRequest事件或者AuthenticateRequest事件調用就行了。
1.11. 使用HttpHandler來調用網址重寫
除了上面所述方法外，網址重寫也可以放入HttpHandler或者HttpHandlerFactory中調用。HttpHandler是一個負責針對特定請求生成相應內容的類，而HttpHandlerFactory返回一個HTTP的實例，該實例針對特定請求生成相應內容。
本節將著眼於為這些ASP.NET頁面創建一個網址重寫的HttpHandlerFactory。創建HttpHandlerFactory必須實現IHTTPHandlerFactory接口，它包括一個GetHandler()方法。ASP.NET引擎在初始化這些HttpModule後做出決定針對該請求調用相應的HttpHandler或者HttpHandlerFactory，在調用HttpHandlerFactory的時候，針對該Web請求以及隨同的其他信息的HttpContext中經過的的HttpHandlerFactory的GetHandler()方法將被ASP.NET引擎調用，HttpHandlerFactory必須返回一個能委托該請求的對象，並且該對象要能實現IHttpHandler接口。
要通過一個HttpHandler來調用網址重寫，可以先創建一個HttpHandlerFactory，它的GetHandler()方法檢查所請求的網址並決定是否需要調用網址重寫。如果要調用網址重寫的話則調用前文所述的已通過檢查的HttpContext對象的RewritePath()方法。最後該HttpHandlerFactory返回一個由類System.Web.UI.PageParser的GetCompiledInstance()方法返回的HttpHandler。（這與內嵌於ASP.NET頁面的HttpHandlerFactory（PageHandlerFactory）的工作原理相同。）
在所有HttpModule被初始化後，HttpHandlerFactory就開始被實例化。把網址重寫放在這些事件場所的最後一個裡頭調用的時候，也會碰到相同的問題：文件授權將會失效。如果非要依賴於Windows驗證和文件驗證的時候，你可能得使用HttpModule來調用網址重寫了。
下一章我們著眼於如何構建一個可重用的網址重寫引擎，使用下文所提的這些示例均以真實案例作為參照，在作者主頁上提供下載。先用用一個簡單的網址重寫的例子來探討如何實現網址重寫，緊接著將利用網址重寫引擎中正則表達式的強大處理能力來展示真正“隱蔽”的網址重寫技術！
1.12. 使用網址重寫引擎實現簡單的網址重寫
為了便於在Web應用程序中實現網址重寫，我構建了一個網址重寫引擎，該引擎提供下列功能：
可以在web.config文件中為頁面開發者定義其所使用的網址重寫引擎的規則；
通過使用正則表達式來使所制定的網址重寫規則具有更加強大的重寫能力；
能夠通過簡單配置即可在HttpModule和HttpHandler中使用網址重寫。
本節只探討通過HttpModule來實現網址重寫，要了解如何通過HttpHandler來實現網址重寫請下載本文提供的代碼。
1.12.1. 設置網址重寫引擎的配置信息
我們來探討一下在web.config中網址重寫規則的配置節。首先必須在web.config文件中指出是否需要在HttpHandler或者HttpModule中調用網址重寫，在web.config中，下文已經包含了兩個已經被注釋掉的配置節：
<!--<HttpModules> <add type="URLRewriter.ModuleRewriter,URLRewriter" name="ModuleRewriter"/></HttpModules>--><!--<httpHandlers> <add verb="*" path="*.aspx" type="URLRewriter.RewriterFactoryHandler,URLRewriter" /></httpHandlers>-->
被注釋掉的<HttpModules>為配置使用HttpModule調用網址重寫；注釋掉的<httpHandler>為配置使用HttpHandler調用網址重寫。
不論配置使用<HttpModules>還是<httpHandlers>調用網址重寫，除此之外還須配置網址重寫規則，一條重寫規則包括兩項字符串：請求URL中的查找模式和針對該模式的匹配成功後的替換字符串。該信息在web.config文件中用下列標簽描述：
<RewriterConfig> <Rules> <RewriterRule> <LookFor>pattern to look for</LookFor> <SendTo>String to replace pattern with </SendTo> </RewriterRule> <RewriterRule> <LookFor>pattern to look for</LookFor> <SendTo>String to replace pattern with </SendTo> </RewriterRule> 
</Rules></RewriterConfig>
每一條規則都用一個<RewriterRule>元素表示，以<LookFor>節表示查詢模式，當查詢模式發現匹配字符串時便用<SendTo>節表示的字符串進行替換。這些規則從上到下進行查詢匹配，如果找到一個匹配則按此規則執行網址重寫，並且停止查找。
配置<LookFor>節要使用正則表達式來進行字符串匹配和替換。（在此我們舉一個例子來說明如何使用正則表達式來對字符串進行匹配和替換。）既然該查找模式是一個正則表達式，那麼要注意避開對正則表達式保留字符串的直接使用。（正則表達式的保留字符串包括有：.，?，^，$，等等，可以通過在前面加上一個反斜線來引用這些保留字符，例如\.表示引用一個句點）
1.12.2. 使用HttpModule來執行網址重寫
創建一個HttpModule很簡單，只要創建一個實現IHttpModule接口的類，該IHttpModule接口定義了兩個方法：
Init(HttpApplication)，該方法在HttpModule初始化時引發，通過該方法為HttpApplication事件調用相應的事件委托；
Dispose()，當相應請求處理結束並發送回IIS調用此方法，通過此方法執行最終所有的清理和回收程序。
為了更加方便地為網址重寫創建HttpModule，從一開始我就創建一個抽象的基類（BaseModuleRewriter），該類實現了IHttpModule接口。在Init(HttpApplication)事件中，它通過BaseModuleRewriter_AuthorizeRequest方法引發了HttpApplication的AuthorizeRequest事件，該BaseModuleRewriter_AuthorizeRequest方法通過該類的Rewrite()方法重寫傳入參數HttpApplication對象的內部請求虛擬路徑（Path）。在BaseModuleRewriter對象中，該Rewrite()方法是抽象的，並且沒有實際內容，但在繼承自該類的對象中必須重載Rewrite()方法並為該方法提供實際內容。
通過對該基類的繼承，所有需要做的工作就是創建一個繼承自BaseModuleRewriter的類，重載Rewrite()方法並在該方法中添加網址重寫邏輯代碼。下文列出BaseModuleRewriter代碼：
public abstract class BaseModuleRewriter : IHttpModule
{
public virtual void Init(HttpApplication app){
// WARNING! This does not work with Windows authentication! // If you are using Windows authentication, // change to app.BeginRequest app.AuthorizeRequest += new EventHandler(this.BaseModuleRewriter_AuthorizeRequest);
} public virtual void Dispose() {} protected virtual void BaseModuleRewriter_AuthorizeRequest(object sender, EventArgs e){ HttpApplication app = (HttpApplication) sender; Rewrite(app.Request.Path, app); } protected abstract void Rewrite(string requestedPath, HttpApplication app);
}
注意：該BaseModuleRewriter類將網址重寫放在AuthorizeRequest事件中調用，如果要使用Windows驗證並使用文件驗證模式時請修改代碼將網址授權放在BeginRequest或者AuthenticateRequest事件中。
ModuleRewriter繼承自BaseModuleRewriter，並真正意義地實現了網址重寫的操作，該類僅包含一個重載了的方法Rewrite()，其內容如下文所示：
protected override void Rewrite(string requestedPath, System.Web.HttpApplication app){ // get the configuration rules RewriterRuleCollection rules = RewriterConfiguration.GetConfig().Rules; // iterate through each rule for(int i = 0; i < rules.Count; i++) { // get the pattern to look for, and // Resolve the Url (convert ~ into the appropriate directory) string lookFor = "^" + RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, rules[i].LookFor) + "$"; // Create a regex (note that IgnoreCase is set) Regex re = new Regex(lookFor, RegexOptions.IgnoreCase); // See if a match is found if (re.IsMatch(requestedPath)) { // match found - do any replacement needed string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.Replace(requestedPath, rules[i].SendTo)); // Rewrite the URL RewriterUtils.RewriteUrl(app.Context, sendToUrl); break; // exit the for loop } }}
該Rewriter()方法以獲取web.config文件中的網址重寫規則的設置為起始，它通過循環訪問各條網址重寫規則，每次均獲取當前規則中的LookFor屬性，用正則表達式驗證並判斷是否查找是否對當前請求的網址是否有匹配。
如果發現一條匹配，將用當前規則的SendTo值對請求的路徑執行一個正則表達式替換，替換後的地址通過參數的形式傳給RewriterUtils.RewriteUrl()方法，RewriterUtils是一個幫助類，它提供一對HttpModule和HttpHandler都可以使用的靜態方法，RewriterUrl()方法只是簡單地調用了HttpContext對象的RewritePath()方法。
注意：你已經注意到了當執行正則表達式匹配和替換的時候調用了一個RewriterUtils.ResolveUrl()方法。該幫助方法簡單地替換了應用程序路徑中“~”的所有實例。
本文附錄中提供所有涉及該網址重寫引擎的代碼下載，我們已經探討了主要的部分，但是還有其它一些組件諸如將web.config文件中XML格式化了的網址重寫規則反序列化至一個對象的類定義、通過HttpHandlerFactory實現網址重寫的類定義等。本文最後三節將通過一些真實案例來探討網址重寫的技術。
1.12.3. 用網址重寫引擎實現簡單的網址重寫
為了更好地示范網址重寫引擎的運行，我們來建立一個ASP.NET Web應用程序來實現簡單的網址重寫引擎。假定我們為一家在線銷售各類商品的公司服務，這些產品劃分為以下類別：
分類編號(CategoryID) 分類名稱(CategoryName)
1 飲料（Beverages）
2 調味品（Condiments）
3 工藝品（Confections）
4 日記本（Diary Products）
... ...
假定已經建立好一個名為ListProductsByCategoryID.aspx的ASP.NET頁面文件，它通過查詢參數獲取一個分類編號，並根據此編號獲取所有該分類下的所有商品。如果用戶想浏覽所銷售的飲料類商品可以通過ListProductsByCategoryID.aspx?CategoryID=1來訪問，如果用戶想浏覽所銷售的日記本類商品可以通過ListProductsByCategoryID.aspx?CategoryID=4來訪問。假定還有一個頁面ListCategories.aspx，它列出所有代售商品的分類編號。
顯然這裡發現了一個網址重寫的案例。對於用戶來說他們所輸入的地址不具有任何實際意義並且不具備任何“隱蔽性”，倒不如使用網址重寫引擎讓用戶去訪問/Products/Baverage.aspx地址，系統將該地址重寫到ListProductsByCategoryID.aspx?CategoryID=1。我們可以在web.config文件中來完成網址重寫任務：
<RewriterConfig> <Rules> <!—- Rules for products lister --> <RewriterRule> <LookFor>~/Products/Baverage.aspx</LookFor> <SendTo如果發現一條匹配，將用當前規則的SendTo值對請求的路徑執行一個正則表達式替換，替換後的地址通過參數的形式傳給RewriterUtils.RewriteUrl()方法，RewriterUtils是一個幫助類，它提供一對HttpModule和HttpHandler都可以使用的靜態方法，RewriterUrl()方法只是簡單地調用了HttpContext對象的RewritePath()方法。<RewriterConfig> <Rules> <!—- Rules for products lister --> <RewriterRule> <LookFor>~/Products/Baverage.aspx</LookFor> <SendTo>~/ListProductsByCategoryID.aspx?CategoryID=1</SendTo> </RewriterRule> </Rules></RewriterConfig>
很明顯地看到，搜索用戶訪問的路徑是否匹配/Products/Baverage.aspx，如果匹配的話，則將網址重寫到/ListProductsByCategoryID.aspx?CategoryID=1。
注意：你會發現<LookFor>節點中避免直接在“Baverage.aspx”中使用句點“.”是因為<LookFor>節點的值是正則表達式的匹配模式，在正則表達式中句點符號是一個特殊字符，它表示匹配任何一個字符，也就是說如果訪問BaverageQaspx時也會發生匹配，為了避免發生這個句點引起的匹配我們得在該句點符號前面加上一個“\”，表示引用句點符號
通過該規則定義，當用戶訪問/Products/Baverage.aspx文件的時候，他們將看到代售的飲料類商品列表信息。圖3為訪問/Products/Baverage.aspx地址時的浏覽器截圖，注意在浏覽器中地址欄上顯示的是用戶輸入的/Products/Baverage.aspx地址，但是實際訪問的地址卻是網址重寫後的/ListProductsByCategoryID.aspx?CategoryID=1。（事實上，在服務器上根本就不存在/Products/Baverage.aspx文件！）
圖三．網址重寫後的對商品分類的請求
和/Products/Baverage.aspx類似，下一步我們添加其它分類的重寫規則，只需簡單地在web.config文件中<Rules>中在添加其他<RewriteRule>節即可。該演示完整的重寫規則集合請參考下載文檔的web.config文件中的定義。
為了讓該網址更具有“隱蔽性”，如果讓用戶把/Products/Baverage.aspx後面Baverage.aspx一段截去，在浏覽器中輸入/Products/來浏覽產品分類列表會更好一些。乍一看，這項任務微不足道，只需添加一條網址重寫規則將/Products/映射到/ListCategories.aspx即可。然而這裡有一個微妙之處，你必須先創建一個/Products/目錄，並在裡面放一個空文件Default.aspx。
要認識為什麼這些額外的步驟是必須的，先回顧一下前文。網址重寫引擎是處於ASP.NET一級的，也就是說，如果ASP.NET沒有獲得處理請求的機會的話，網址重寫引擎就不能對輸入的網址請求作出判斷。此外，IIS僅在請求文件包含相應擴展名時才將請求轉交給ASP.NET引擎。如果用戶訪問/Products/，IIS並不知道其擴展名是什麼，於是它檢查該目錄下的文件看是否包含有默認首頁文件名（Default.aspx,Default.htm,Default.asp,等等，這些文件名在IIS管理工具對話框中Web服務器屬性對話框中的文檔標簽中定義。）當然，如果/Products/目錄不存在的話，IIS將返回一個HTTP 404錯誤。
所以我們需要創建一個/Products/目錄並在該目錄下額外創建一個空文件Default.aspx，IIS會檢查該目錄下的文件，發現有一個默認文件名Default.aspx，於是將請求轉交給ASP.NET，這樣，網址重寫引擎才能生效。
<RewriterRule> <LookFor>~/Products/Default.aspx</LookFor> <SendTo>~ListCategories.aspx</SendTo></RewriterRule>
通過該規則，用戶訪問/Products/Default.aspx或者訪問/Products/都可以看到如圖四所示的產品分類列表。
圖四.在網址上添加“隱蔽性”
1.12.4.處理回送數據
如果要重寫的網址上包含有服務器端Web Form並執行數據回送，當該Web Form回送數據時會暴露出真實的網址，也就是說，當用戶訪問/Products/Baverage.aspx時，浏覽器上地址欄顯示的也是/Products/Baverage.aspx，但是實際上是訪問/ListProdutsByCategoryID.aspx?CategoryID=1的內容，如果ListProductsByCategoryID.aspx頁面執行了數據回送的話，用戶被數據回送定向給原始的/ListProductByCategoryID.aspx?CategoryID=1頁面上，而不是/Products/Baverage.aspx頁面。這雖然不是什麼大問題，但是用戶會覺察到點擊一個按鈕時網址發生了的變化，這也許會令人不安，因為如果出於網址安全的角度來說，直接把真實的網址暴露出來了。
之所以發生這種現象的原因是當Web Form在呈現之時就明確地設置其action屬性為當前Request對象中文件路徑的值。當然，在Web Form呈現之時，從/Produts/Baverage.aspx到/ListProductsByCategoryID.aspx?CategoryID=1的網址重寫就已經執行完畢了，這意味著Request對象所匯報的是當前用戶所訪問的地址是/ListProductsByCategoryID.aspx?CategoryID=1。這麼看來，只需讓該服務器端表單在呈現之時不呈現action屬性即可解決問題了。（對浏覽器來說，如果不設置action屬性的話，那麼在提交的時候將使用其默認值。）
然而不幸的是該Web Form不會允許你指定action屬性，也不會允許你通過設置一些屬性來達到禁用呈現action屬性的目的。得自行繼承System.Web.HtmlControls.HtmlForm這個類，並重載該類的RenderAttribute()方法，明確指出該類不呈現acton屬性。
感謝繼承這個強大的功能，使得我們很簡單就獲取了HtmlForm這個類下所有的功能定義，只需少量幾行代碼就達到所需目的，完整代碼如下所示：
namespace ActionlessForm
{
public class Form:System.Web.UI.HtmlControls.HtmlForm
{ protected override void RenderAttributes(System.Web.UI.HtmlTextWriter writer) { writer.WriteAttribute("name",this.Name); base.Attributes.Remove("name"); writer.WriteAttribute("method",this.Method); base.Attributes.Remove("method"); this.Attributes.Render(writer); base.Attributes.Remove("action"); if (base.ID!=null) { writer.WriteAttribute("id",this.ClientID);
} } }
}
對RenderAttributes()方法重載的代碼包含了原類HtmlForm的RenderAttributes()方法全部的代碼內容，只是簡單地去掉了設置action屬性這一節。（我參考了Lutz Roeder的Reflecter一文中類HtmlForm的源代碼）
當創建並編譯了這個類後，將其添加到引用目錄即可在該ASP.NET Web應用程序中使用。為了將原有HtmlForm類替換，只需簡單地在頁面頂部添加下列代碼：
<%@ Register TagPrefix="skm" Namespace="ActionlessForm" Assembly="ActionlessForm"%>
然後將<Form runat=”server”>標簽替換為
<skm:Form id="Form1" method="post" runat="Server">
並將結束標記</Form>替換為
<skm:Form>
你可以查看該文檔相關下載中的ListProductsByCategoryID.aspx文件中的自定義Web Form，該下載已經提供了完整的Visual Studio.NET項目文件包。
注意：如果你打算進行網址重寫的地址不執行數據回送，則沒有必要使用該自定義Web Form的類。
1.13. 創建真正“隱蔽”的網址
上一節簡單網址重寫的示例展示了如何通過新的網址重寫規則來輕松地配置網址重寫引擎，本節將通過出眾的正則表達式來展示網址重寫的強大威力。
時下正在流行Blog，很多人都擁有一個自己的Blog。不論你是否對Blog感到陌生，他們正在不斷地更新自己的Blog頁面，這些頁面就像一個個人日記本一樣。大多數Bloger只是簡單地記錄每天發生的事情，也有一些聚焦於某一主題，比如影評、球迷組織、電腦技術等。
Blog可以在任何地點由作者進行更新，更新次數可以是一天多次，也可以是一周一兩次。在Blog頁面上只顯示最近10條更新，但事實上所有的Blog軟件都提供了存檔記錄，訪客可以閱讀其歷史記錄。有了“隱蔽”的網址，Blog應用程序將變得更加強大。假定你通過/2004/02/14.aspx來查詢自己的Blog上的文章，你會為閱讀到2004年2月14日的Blog感到驚訝嗎？此外你可能為了訪問2004年2月所有的Blog而將該地址裁減為/2004/02/，要訪問2004年所有的Blog，你可能會試著去訪問/2004/。
在維護一個Blog的時候，如果將這種具有“隱蔽性”的網址提供給用戶將會更好。實際上很多Blog引擎都提供了這種網址重寫的功能，現在來看看這些是如何通過網址重寫實現的。
首先，我們需要一個頁面能夠分別按照年、月、日分別顯示Blog的內容。假定現在已經做好了一個頁面文件ShowBlogContent.aspx，它能分別獲取年、月、日的查詢參數，要查看2004年2月14日所發的帖子，我們可以訪問/ShowBlogContent.aspx?year=2004&month=2&day=14，要浏覽2004年2月的數據可以訪問/ShowBlogContent.aspx?year=2004&month=2，要查詢2004年所有數據可以訪問/ShowBlogContent.aspx?year=2004。（在下載文件中提供ShowBlogContent.aspx源代碼。）
然後，當用戶訪問/2004/02/14.aspx時，我們需要將他訪問的網址重寫到/ShowBlogContent.aspx?year=2004&month=2&day=14上。這裡需要制定三條網址重寫規則：當指定訪問年月日時、當指定訪問年月時和當指定訪問年時。
<RewriterConfig> <Rules> <!-- Rules for Blog Content Displayer --> <RewriterRule> <LookFor>~/(d{4})/(d{2})/(d{2}).aspx</LookFor> <SendTo>~/ShowBlogContent.aspx?year=$1&month=$2&day=$3</SendTo> </RewriterRule> <RewriterRule> <LookFor>~/(d{4})/(d{2})/Default.aspx</LookFor> <SendTo><![CDATA[~/ShowBlogContent.aspx?year=$1&month=$2]]></SendTo> </RewriterRule> <RewriterRule> <LookFor>~/(d{4})/Default.aspx</LookFor> <SendTo>~/ShowBlogContent.aspx?year=$1</SendTo> </RewriterRule> </Rules></RewriterConfig>
這些網址重寫規則展示了正則表達式的強大威力。第一條規則按照(\d{4})/(\d{2})/(\d{2})\.aspx模式進行查找，通俗的說，它查找是否包含匹配xxxx/xx/xx.aspx格式的字符串，其中x表示數字，每一組數字必須用圓括號括起來，這樣可以在相應<SendTo>節內引用圓括號內的匹配字符串。我們可以使用$1、$2、$3來分別引用前面匹配的圓括號組，其中$1，$2，$3分別表示所匹配的第一、第二、第三個圓括號組。
注意：由於web.config是XML格式的文檔，所以在文本域內必須回避直接使用一些特殊字符，如：&，<和>符號等。在第一條網址重寫規則的<SendTo>節中用&來表示引用&符號，在第二條網址重寫規則的<SendTo>節中用<![CDATA[...]]>元素來表示其中所有的內容都是文本域，不再需要用轉義字符來表示引用。這兩種方法都可以實現同樣的目的。
下面圖五、圖六、圖七都顯示出網址重寫的運行狀況。這些數據都真實地摘自作者的Blog（http://ScottOnWritting.net），圖五顯示2003年11月7日的帖子，圖六顯示所有2003年11月的帖子，圖七顯示2003年所有帖子。
圖五.顯示2003年11月7日的帖子
圖六. 顯示2003年11月所有的帖子
圖七. 顯示2003年所有的帖子
注意：要使用網址重寫引擎，強烈推薦在<LookFor>節中使用正則表達式。如果你對正則表達式不是很熟悉，可以先閱讀作者本人寫的一篇文章An Introduction to Regular Expressions，此外還可以在RegexLib.com 上查詢常用的正則表達式，或把你自己設計的正則表達式提交到該站點共享使用。
1.14. 創建必須的目錄結構
當IIS接收到對/2004/03/19.aspx的請求時，他發現文件擴展名.aspx，便將該請求轉交給ASP.NET引擎處理，在ASP.NET 引擎中傳遞時，該地址被重寫到/ShowBlogContent.aspx?year=2004&month=3&day=19，最後用戶將看到該Blog上2004年3月19日所有的帖子，但是在用戶訪問/2004/03/時會發生什麼呢？除非已經存在一個/2004/01/的目錄，否則IIS將返回一個404錯誤，而且該目錄下還必須要有一個默認頁面Default.aspx，IIS才能將請求轉交給ASP.NET引擎處理。
通過這種方法你得手動為每一年的Blog創建一個年份的目錄並在該年份下放置一個默認文件Default.aspx，而且還得在該年份目錄下創建每一月的目錄，從01、02、...、12，每一個目錄下也要防止一個默認文件Default.aspx。（回想前面的例子，為了將/Products/重寫到/ListCategories.aspx也是要建立一個/Products/目錄並放置一個默認Default.aspx文件。
很明顯，這樣創建目錄結構的過程是很痛苦的。解決這種問題的一個辦法就是設置IIS將所有接收的請求都轉交給ASP.NET引擎來處理，這種方法，甚至連訪問這種地址/2004/04/，IIS都如實地將其轉交給ASP.NET引擎處理，這種方法造成ASP.NET引擎得處理所有傳入的請求，包括css文件，圖片文件、Javascript文件以及Flash文件等等。
關於對所有類型文件的處理的詳細討論已經超出了本書范圍。有關在ASP.NET Web應用程序中使用這些技術的例子請訪問 .Text 這個開源的Blog。.Text 可以通過配置將所有請求都轉交給ASP.NET處理。它使用了一個自定義的HttpHandler來處理所有類型的文件類型，這個自定義的HttpHandler可以識別並判斷如何處理所有的文件類型。（圖像文件、CSS文件等等。）
1.15. 結束語
本文探討了通過類HttpContext類的RewriteUrl()方法來實現ASP.NET一級的網址重寫，正如我們所看到那樣，RewriteUrl()方法在修改這個特有的HttpContext的Request的屬性時也修改了所請求的文件和路徑。實際得到的效果就是在用戶訪問其特有的網址的時候，他實際卻是在服務器端請求另一個與此不同的網址。
網址重寫不但可以在HttpModule中執行，也可以在HttpHandler中運行。本文我們探討了在一個HttpModule中執行網址重寫，也研究了一下網址重寫在ASP.NET中的各個不同場所的情況。
當然，在ASP.NET一級的網址重寫中，只有在IIS成功地將請求轉交給ASP.NET引擎後才能成功地執行，當用戶請求一個擴展名為.aspx的文件時這很自然地發生。然而，如果要讓用戶輸入一個實際並不存在的網址，通過網址重寫到另一個存在的aspx頁面，你必須為該請求創建相應的目錄和默認的Default.aspx頁面，除非配置IIS讓它把所有的請求都轉交給IIS處理，但是這種方式盲目地將所有請求都轉交給了ASP.NET引擎。
1.16. 參考
本文源代碼下載地址：http://download.microsoft.com/download/0/4/6/0463611e-a3f9-490d-a08c-877a83b797cf/MSDNURLRewriting.msi
《深入研究IIS與ASP.NET》(Inside IIS and ASP.NET) 作者：Michele Leroux Bustamante
工作參考：網址重寫是一個頗受歡迎的主題，不論是ASP.NET還是其他競爭對手都對其表示出巨大的關注。例如：Apache Web Server提供了一個叫做mod_rewriting的模塊，mod_rewriting是個功能完善的網址重寫引擎，它提供基於HTTP 頭信息和服務器參數環境的網址重寫功能，甚至還提供用正則表達式來創建網址重寫規則。有關mod_rewriting更多信息請參考A User's Guide to URL Rewriting with the Apache Web Server《Apache Web Server網址重寫用戶向導》。
這裡有相當數量的關於ASP.NET級別下網址重寫的文章：
Rewrite.NET - A URL Rewriting Engine for .NET探討模擬mod_rewriting的正則表達式描述的網址重寫規則來實現ASP.NET下網址重寫；
URL Rewriting With ASP.NET提供對ASP.NET下網址重寫能力的總的概述；
Ian Griffiths有一個Blog，上面有許多有關在ASP.NET中實現網址重寫的建議，比如本文所提到的考慮到數據回送時的做法；
Fabrice Marguerie和Jason Salas都各有一個Blog，在上面可以找到有關將ASP.NET網址重寫來推動搜索引擎的查找替換的文章。
（Fabrice Marguerie: http://weblogs.asp.net/fmarguerie/archive/2003/12/24/45712.aspx）
（Jason Salas: http://weblogs.asp.net/jasonsalas/archive/2003/12/14/43404.aspx）
</RewriterRule> </Rules></RewriterConfig>
很明顯地看到，搜索用戶訪問的路徑是否匹配/Products/Baverage.aspx，如果匹配的話，則將網址重寫到/ListProductsByCategoryID.aspx?CategoryID=1。
注意：你會發現<LookFor>節點中避免直接在“Baverage.aspx”中使用句點“.”是因為<LookFor>節點的值是正則表達式的匹配模式，在正則表達式中句點符號是一個特殊字符，它表示匹配任何一個字符，也就是說如果訪問BaverageQaspx時也會發生匹配，為了避免發生這個句點引起的匹配我們得在該句點符號前面加上一個“\”，表示引用句點符號
通過該規則定義，當用戶訪問/Products/Baverage.aspx文件的時候，他們將看到代售的飲料類商品列表信息。圖3為訪問/Products/Baverage.aspx地址時的浏覽器截圖，注意在浏覽器中地址欄上顯示的是用戶輸入的/Products/Baverage.aspx地址，但是實際訪問的地址卻是網址重寫後的/ListProductsByCategoryID.aspx?CategoryID=1。（事實上，在服務器上根本就不存在/Products/Baverage.aspx文件！）
圖三．網址重寫後的對商品分類的請求
和/Products/Baverage.aspx類似，下一步我們添加其它分類的重寫規則，只需簡單地在web.config文件中<Rules>中在添加其他<RewriteRule>節即可。該演示完整的重寫規則集合請參考下載文檔的web.config文件中的定義。
為了讓該網址更具有“隱蔽性”，如果讓用戶把/Products/Baverage.aspx後面Baverage.aspx一段截去，在浏覽器中輸入/Products/來浏覽產品分類列表會更好一些。乍一看，這項任務微不足道，只需添加一條網址重寫規則將/Products/映射到/ListCategories.aspx即可。然而這裡有一個微妙之處，你必須先創建一個/Products/目錄，並在裡面放一個空文件Default.aspx。
要認識為什麼這些額外的步驟是必須的，先回顧一下前文。網址重寫引擎是處於ASP.NET一級的，也就是說，如果ASP.NET沒有獲得處理請求的機會的話，網址重寫引擎就不能對輸入的網址請求作出判斷。此外，IIS僅在請求文件包含相應擴展名時才將請求轉交給ASP.NET引擎。如果用戶訪問/Products/，IIS並不知道其擴展名是什麼，於是它檢查該目錄下的文件看是否包含有默認首頁文件名（Default.aspx,Default.htm,Default.asp,等等，這些文件名在IIS管理工具對話框中Web服務器屬性對話框中的文檔標簽中定義。）當然，如果/Products/目錄不存在的話，IIS將返回一個HTTP 404錯誤。
所以我們需要創建一個/Products/目錄並在該目錄下額外創建一個空文件Default.aspx，IIS會檢查該目錄下的文件，發現有一個默認文件名Default.aspx，於是將請求轉交給ASP.NET，這樣，網址重寫引擎才能生效。
<RewriterRule> <LookFor>~/Products/Default.aspx</LookFor> <SendTo>~ListCategories.aspx</SendTo></RewriterRule>
通過該規則，用戶訪問/Products/Default.aspx或者訪問/Products/都可以看到如圖四所示的產品分類列表。
圖四.在網址上添加“隱蔽性”
1.12.4.處理回送數據
如果要重寫的網址上包含有服務器端Web Form並執行數據回送，當該Web Form回送數據時會暴露出真實的網址，也就是說，當用戶訪問/Products/Baverage.aspx時，浏覽器上地址欄顯示的也是/Products/Baverage.aspx，但是實際上是訪問/ListProdutsByCategoryID.aspx?CategoryID=1的內容，如果ListProductsByCategoryID.aspx頁面執行了數據回送的話，用戶被數據回送定向給原始的/ListProductByCategoryID.aspx?CategoryID=1頁面上，而不是/Products/Baverage.aspx頁面。這雖然不是什麼大問題，但是用戶會覺察到點擊一個按鈕時網址發生了的變化，這也許會令人不安，因為如果出於網址安全的角度來說，直接把真實的網址暴露出來了。
之所以發生這種現象的原因是當Web Form在呈現之時就明確地設置其action屬性為當前Request對象中文件路徑的值。當然，在Web Form呈現之時，從/Produts/Baverage.aspx到/ListProductsByCategoryID.aspx?CategoryID=1的網址重寫就已經執行完畢了，這意味著Request對象所匯報的是當前用戶所訪問的地址是/ListProductsByCategoryID.aspx?CategoryID=1。這麼看來，只需讓該服務器端表單在呈現之時不呈現action屬性即可解決問題了。（對浏覽器來說，如果不設置action屬性的話，那麼在提交的時候將使用其默認值。）
然而不幸的是該Web Form不會允許你指定action屬性，也不會允許你通過設置一些屬性來達到禁用呈現action屬性的目的。得自行繼承System.Web.HtmlControls.HtmlForm這個類，並重載該類的RenderAttribute()方法，明確指出該類不呈現acton屬性。
感謝繼承這個強大的功能，使得我們很簡單就獲取了HtmlForm這個類下所有的功能定義，只需少量幾行代碼就達到所需目的，完整代碼如下所示：
namespace ActionlessForm{ public class Form:System.Web.UI.HtmlControls.HtmlForm { protected override void RenderAttributes(System.Web.UI.HtmlTextWriter writer) { writer.WriteAttribute("name",this.Name); base.Attributes.Remove("name"); writer.WriteAttribute("method",this.Method); base.Attributes.Remove("method"); this.Attributes.Render(writer); base.Attributes.Remove("action"); if (base.ID!=null) { writer.WriteAttribute("id",this.ClientID); } } }}
對RenderAttributes()方法重載的代碼包含了原類HtmlForm的RenderAttributes()方法全部的代碼內容，只是簡單地去掉了設置action屬性這一節。（我參考了Lutz Roeder的Reflecter一文中類HtmlForm的源代碼）
當創建並編譯了這個類後，將其添加到引用目錄即可在該ASP.NET Web應用程序中使用。為了將原有HtmlForm類替換，只需簡單地在頁面頂部添加下列代碼：
<%@ Register TagPrefix="skm" Namespace="ActionlessForm" Assembly="ActionlessForm"%>
然後將<Form runat=”server”>標簽替換為
<skm:Form id="Form1" method="post" runat="Server">
並將結束標記</Form>替換為
<skm:Form>
你可以查看該文檔相關下載中的ListProductsByCategoryID.aspx文件中的自定義Web Form，該下載已經提供了完整的Visual Studio.NET項目文件包。
注意：如果你打算進行網址重寫的地址不執行數據回送，則沒有必要使用該自定義Web Form的類。
1.13. 創建真正“隱蔽”的網址
上一節簡單網址重寫的示例展示了如何通過新的網址重寫規則來輕松地配置網址重寫引擎，本節將通過出眾的正則表達式來展示網址重寫的強大威力。
時下正在流行Blog，很多人都擁有一個自己的Blog。不論你是否對Blog感到陌生，他們正在不斷地更新自己的Blog頁面，這些頁面就像一個個人日記本一樣。大多數Bloger只是簡單地記錄每天發生的事情，也有一些聚焦於某一主題，比如影評、球迷組織、電腦技術等。
Blog可以在任何地點由作者進行更新，更新次數可以是一天多次，也可以是一周一兩次。在Blog頁面上只顯示最近10條更新，但事實上所有的Blog軟件都提供了存檔記錄，訪客可以閱讀其歷史記錄。有了“隱蔽”的網址，Blog應用程序將變得更加強大。假定你通過/2004/02/14.aspx來查詢自己的Blog上的文章，你會為閱讀到2004年2月14日的Blog感到驚訝嗎？此外你可能為了訪問2004年2月所有的Blog而將該地址裁減為/2004/02/，要訪問2004年所有的Blog，你可能會試著去訪問/2004/。
在維護一個Blog的時候，如果將這種具有“隱蔽性”的網址提供給用戶將會更好。實際上很多Blog引擎都提供了這種網址重寫的功能，現在來看看這些是如何通過網址重寫實現的。
首先，我們需要一個頁面能夠分別按照年、月、日分別顯示Blog的內容。假定現在已經做好了一個頁面文件ShowBlogContent.aspx，它能分別獲取年、月、日的查詢參數，要查看2004年2月14日所發的帖子，我們可以訪問/ShowBlogContent.aspx?year=2004&month=2&day=14，要浏覽2004年2月的數據可以訪問/ShowBlogContent.aspx?year=2004&month=2，要查詢2004年所有數據可以訪問/ShowBlogContent.aspx?year=2004。（在下載文件中提供ShowBlogContent.aspx源代碼。）
然後，當用戶訪問/2004/02/14.aspx時，我們需要將他訪問的網址重寫到/ShowBlogContent.aspx?year=2004&month=2&day=14上。這裡需要制定三條網址重寫規則：當指定訪問年月日時、當指定訪問年月時和當指定訪問年時。
<RewriterConfig> <Rules> <!-- Rules for Blog Content Displayer --> <RewriterRule> <LookFor>~/(d{4})/(d{2})/(d{2}).aspx</LookFor> <SendTo>~/ShowBlogContent.aspx?year=$1&month=$2&day=$3</SendTo> </RewriterRule> <RewriterRule> <LookFor>~/(d{4})/(d{2})/Default.aspx</LookFor> <SendTo><![CDATA[~/ShowBlogContent.aspx?year=$1&month=$2]]></SendTo> </RewriterRule> <RewriterRule> <LookFor>~/(d{4})/Default.aspx</LookFor> <SendTo>~/ShowBlogContent.aspx?year=$1</SendTo> </RewriterRule> </Rules></RewriterConfig>
這些網址重寫規則展示了正則表達式的強大威力。第一條規則按照(\d{4})/(\d{2})/(\d{2})\.aspx模式進行查找，通俗的說，它查找是否包含匹配xxxx/xx/xx.aspx格式的字符串，其中x表示數字，每一組數字必須用圓括號括起來，這樣可以在相應<SendTo>節內引用圓括號內的匹配字符串。我們可以使用$1、$2、$3來分別引用前面匹配的圓括號組，其中$1，$2，$3分別表示所匹配的第一、第二、第三個圓括號組。
注意：由於web.config是XML格式的文檔，所以在文本域內必須回避直接使用一些特殊字符，如：&，<和>符號等。在第一條網址重寫規則的<SendTo>節中用&來表示引用&符號，在第二條網址重寫規則的<SendTo>節中用<![CDATA[...]]>元素來表示其中所有的內容都是文本域，不再需要用轉義字符來表示引用。這兩種方法都可以實現同樣的目的。
下面圖五、圖六、圖七都顯示出網址重寫的運行狀況。這些數據都真實地摘自作者的Blog（http://ScottOnWritting.net），圖五顯示2003年11月7日的帖子，圖六顯示所有2003年11月的帖子，圖七顯示2003年所有帖子。
圖五.顯示2003年11月7日的帖子
圖六. 顯示2003年11月所有的帖子
圖七. 顯示2003年所有的帖子
注意：要使用網址重寫引擎，強烈推薦在<LookFor>節中使用正則表達式。如果你對正則表達式不是很熟悉，可以先閱讀作者本人寫的一篇文章An Introduction to Regular Expressions，此外還可以在RegexLib.com 上查詢常用的正則表達式，或把你自己設計的正則表達式提交到該站點共享使用。
1.14. 創建必須的目錄結構
當IIS接收到對/2004/03/19.aspx的請求時，他發現文件擴展名.aspx，便將該請求轉交給ASP.NET引擎處理，在ASP.NET 引擎中傳遞時，該地址被重寫到/ShowBlogContent.aspx?year=2004&month=3&day=19，最後用戶將看到該Blog上2004年3月19日所有的帖子，但是在用戶訪問/2004/03/時會發生什麼呢？除非已經存在一個/2004/01/的目錄，否則IIS將返回一個404錯誤，而且該目錄下還必須要有一個默認頁面Default.aspx，IIS才能將請求轉交給ASP.NET引擎處理。
通過這種方法你得手動為每一年的Blog創建一個年份的目錄並在該年份下放置一個默認文件Default.aspx，而且還得在該年份目錄下創建每一月的目錄，從01、02、...、12，每一個目錄下也要防止一個默認文件Default.aspx。（回想前面的例子，為了將/Products/重寫到/ListCategories.aspx也是要建立一個/Products/目錄並放置一個默認Default.aspx文件。
很明顯，這樣創建目錄結構的過程是很痛苦的。解決這種問題的一個辦法就是設置IIS將所有接收的請求都轉交給ASP.NET引擎來處理，這種方法，甚至連訪問這種地址/2004/04/，IIS都如實地將其轉交給ASP.NET引擎處理，這種方法造成ASP.NET引擎得處理所有傳入的請求，包括css文件，圖片文件、Javascript文件以及Flash文件等等。
關於對所有類型文件的處理的詳細討論已經超出了本書范圍。有關在ASP.NET Web應用程序中使用這些技術的例子請訪問 .Text 這個開源的Blog。.Text 可以通過配置將所有請求都轉交給ASP.NET處理。它使用了一個自定義的HttpHandler來處理所有類型的文件類型，這個自定義的HttpHandler可以識別並判斷如何處理所有的文件類型。（圖像文件、CSS文件等等。）
1.15. 結束語
本文探討了通過類HttpContext類的RewriteUrl()方法來實現ASP.NET一級的網址重寫，正如我們所看到那樣，RewriteUrl()方法在修改這個特有的HttpContext的Request的屬性時也修改了所請求的文件和路徑。實際得到的效果就是在用戶訪問其特有的網址的時候，他實際卻是在服務器端請求另一個與此不同的網址。
網址重寫不但可以在HttpModule中執行，也可以在HttpHandler中運行。本文我們探討了在一個HttpModule中執行網址重寫，也研究了一下網址重寫在ASP.NET中的各個不同場所的情況。
當然，在ASP.NET一級的網址重寫中，只有在IIS成功地將請求轉交給ASP.NET引擎後才能成功地執行，當用戶請求一個擴展名為.aspx的文件時這很自然地發生。然而，如果要讓用戶輸入一個實際並不存在的網址，通過網址重寫到另一個存在的aspx頁面，你必須為該請求創建相應的目錄和默認的Default.aspx頁面，除非配置IIS讓它把所有的請求都轉交給IIS處理，但是這種方式盲目地將所有請求都轉交給了ASP.NET引擎。
1.16. 參考
本文源代碼下載地址：http://download.microsoft.com/download/0/4/6/0463611e-a3f9-490d-a08c-877a83b797cf/MSDNURLRewriting.msi
《深入研究IIS與ASP.NET》(Inside IIS and ASP.NET) 作者：Michele Leroux Bustamante
工作參考：網址重寫是一個頗受歡迎的主題，不論是ASP.NET還是其他競爭對手都對其表示出巨大的關注。例如：Apache Web Server提供了一個叫做mod_rewriting的模塊，mod_rewriting是個功能完善的網址重寫引擎，它提供基於HTTP 頭信息和服務器參數環境的網址重寫功能，甚至還提供用正則表達式來創建網址重寫規則。有關mod_rewriting更多信息請參考A User's Guide to URL Rewriting with the Apache Web Server《Apache Web Server網址重寫用戶向導》。
這裡有相當數量的關於ASP.NET級別下網址重寫的文章：
Rewrite.NET - A URL Rewriting Engine for .NET探討模擬mod_rewriting的正則表達式描述的網址重寫規則來實現ASP.NET下網址重寫；
URL Rewriting With ASP.NET提供對ASP.NET下網址重寫能力的總的概述；
Ian Griffiths有一個Blog，上面有許多有關在ASP.NET中實現網址重寫的建議，比如本文所提到的考慮到數據回送時的做法；
Fabrice Marguerie和Jason Salas都各有一個Blog，在上面可以找到有關將ASP.NET網址重寫來推動搜索引擎的查找替換的文章。
（Fabrice Marguerie: http://weblogs.asp.net/fmarguerie/archive/2003/12/24/45712.aspx）
（Jason Salas: http://weblogs.asp.net/jasonsalas/archive/2003/12/14/43404.aspx）
