摘要：介紹如何使用 Microsoft ASP.NET 執行動態 URL 重寫。URL 重寫是截取傳入 Web 請求并自動將請求重定向到其他 URL 的過程。討論實現 URL 重寫的各種技術，并介紹執行 URL 重寫的一些實際情況。

引言讓我們花點時間來看一下網站上的一些 URL。您是否發現一些類似于 http://www.51aspx.com/info/dispEmp%20...%20pID=459-099&;type=summary 的 URL？或者，您可能將一系列網頁從一個目錄或網站移動到另一個目錄或網站，結果導致已將舊 URL 用作書簽的訪問者斷開鏈接。在本文中，我們將了解如何通過將 http://51aspx.com/CV/UrlReWriter//dispEmp ... pID=459-099&;type=summary 替換為類似于 http://51aspx.com/CV/UrlReWriter/ 的網址，使用 URL 重寫將那些冗長的 URL 縮寫為富有意義且容易記憶的 URL。我們還將了解如何將 URL 重寫用于創建智能 404 錯誤。
URL 重寫是截取傳入 Web 請求并自動將請求重定向到其他資源的過程。執行 URL 重寫時，通常會檢查被請求的 URL，并基于 URL 的值將請求重定向到其他 URL。例如，在進行網站重組而將 /people/ 目錄下的所有網頁移動到 /info/employees/ 目錄中時，您可能希望使用 URL 重寫來檢查 Web 請求是否指向了 /people/ 目錄中的文件。如果請求指向 /people/ 目錄中的文件，您可能希望自動將請求重定向到 /info/employees/ 目錄中的同一文件。
使用傳統的 ASP，應用 URL 重寫的唯一方法是編寫 ISAPI 篩選器，或者購買提供 URL 重寫功能的第三方產品。但是，使用 Microsoft? ASP.NET，您可以通過很多方法來輕松地創建您自己的 URL 重寫軟件。本文討論了可供 ASP.NET 開發人員實現 URL 重寫的各種技術，然后討論了 URL 重寫的一些實際使用情況。在深入討論 URL 重寫的技術細節之前，讓我們先看一些可以使用 URL 重寫的日常情景。
返回頁首

URL 重寫的常見用法創建數據驅動的 ASP.NET 網站時，通常會產生一個單個的網頁，該網頁基于查詢字符串參數顯示數據庫數據的子集。例如，在設計電子商務站點時，您的任務之一便是允許用戶瀏覽待售產品。為此，您可以創建一個名為 displayCategory.aspx 的頁面，該頁面將顯示給定類別的產品。可以通過查詢字符串參數來指定要查看的該類別的產品。也就是說，如果用戶要瀏覽待售的 Widget 產品，并且所有 Widget 產品的 CategoryID 均為 5，則用戶可以訪問以下網址：http://51aspx.com/CV/UrlReWriter/displayCategory.aspx?CategoryID=5。
創建具有此類 URL 的網站有兩點不足：首先，從最終用戶的角度考慮，URL http://51aspx.com/CV/UrlReWriter/displayCategory.aspx?CategoryID=5 比較雜亂。可用性專家 Jakob Neilsen 建議遵循以下標準來選擇 URL：

• 簡短。
• 易于鍵入。
• 可以看出站點的結構。
• “可刪節”，允許用戶通過刪除 URL 的組成部分來瀏覽站點。

我還要增加一條標準，即，URL 應該便于記憶。URL http://yousite.com/displayCategory.aspx?CategoryID=5 不符合 Neilsen 的任何標準，也不容易記住。要求用戶鍵入查詢字符串值將使 URL 的鍵入變得非常困難，并且只有了解查詢字符串參數的用途及其名稱/值對結構的富有經驗的 Web 開發人員才能夠對 URL 進行“刪節”。
較好的方法是允許使用切合實際且容易記憶的 URL，如 http://51aspx.com/CV/UrlReWriter/。只要看一眼 URL，您便可以推斷出將要顯示的內容 -- 有關 Widget 的信息。此 URL 也很容易記住和共享。我可以告訴我的同事“請查看 yoursite.com/products/Widgets，”，她可能無需再次問我 URL 是什么即可打開該頁面。（嘗試一下，您只需說出“Amazon.com 頁面”即可！）此 URL 還將顯示出來，并且應該是“可刪節”的。也就是說，如果用戶刪去 URL 的末端，鍵入 http://51aspx.com/CV/UrlReWriter/，他們應該看到所有產品的列表，或者至少應該看到他們可以查看的所有類別的產品列表。
注意：要獲得“可刪節”URL 的最好示例，可考慮使用由許多 blog 引擎生成的 URL。要查看 2004 年 1 月 28 日的帖子，用戶可以訪問諸如 http://someblog.com/2004/01/28 的 URL。如果該 URL 被刪節為 http://someblog.com/2004/01，用戶將看到 2004 年 1 月的所有帖子。將該 URL 進一步刪節為 http://someblog.com/2004 將顯示 2004 年的所有帖子。
除了簡化 URL 之外，URL 重寫還經常用于處理網站重組，以免導致大量鏈接斷開或書簽過期。
返回頁首

請求到達 IIS 時將會發生什么情況在正式研究 URL 如何實現重寫之前，應首先了解 Microsoft? Internet Information Services (IIS) 如何處理傳入請求，這一點非常重要。當請求到達 IIS Web 服務器時，IIS 檢查被請求文件的擴展名以確定如何處理該請求。IIS 可以自行處理請求（如 HTML 頁面、圖像以及其他靜態內容），或者將請求路由到 ISAPI 擴展。（ISAPI 擴展是一個處理傳入 Web 請求的非托管編譯類。其任務是生成被請求資源的內容。）
例如，當傳入針對 Info.asp 網頁的請求時，IIS 會將此消息路由到 asp.dll ISAPI 擴展。然后，該 ISAPI 擴展將加載被請求的 ASP 頁面，執行該頁面，并將所呈現的 HTML 返回給 IIS，然后，IIS 將該 HTML 發送回請求客戶端。對于 ASP.NET 頁面，IIS 會將此消息路由到 aspnet_isapi.dll ISAPI 擴展。然后，aspnet_isapi.dll ISAPI 擴展將處理操作傳遞給托管的 ASP.NET 輔助進程，該輔助程序將處理請求，并返回 ASP.NET 網頁的呈現 HTML。
您可以自定義 IIS，以指定擴展名與 ISAPI 擴展的映射關系。圖 1 顯示了 Internet Information Services 管理工具的“應用程序配置”對話框。請注意，與 ASP.NET 有關的擴展名（.aspx、ascx、config、asmx、rem、cs、vb 及其他）均已映射到 aspnet_isapi.dll ISAPI 擴展。

圖 1. 已配置的文件擴展名映射
討論 IIS 如何管理傳入請求稍稍超出了本文范圍。但是可以在 Michele Leroux Bustamante 的文章 Inside IIS and ASP.NET 中找到對此內容的深入討論。ASP.NET 引擎僅處理那些擴展名已明確映射至 IIS 中的 aspnet_isapi.dll 的傳入 Web 請求，了解這一點非常重要。
使用 ISAPI 篩選器檢查請求IIS 除了可以將傳入 Web 請求的文件擴展名映射到相應的 ISAPI 擴展之外，還將執行許多其他任務。例如，IIS 將嘗試對發出請求的用戶進行身份驗證，并確定通過身份驗證的用戶是否有權限訪問被請求的文件。在處理請求的有效期內，IIS 將經歷幾個狀態。在每個狀態下，IIS 都將引發可以使用 ISAPI 篩選器以編程方式進行處理的事件。
與 ISAPI 擴展一樣，ISAPI 篩選器是在 Web 服務器上安裝的非托管代碼塊。ISAPI 擴展被設計為可以響應針對特定文件類型的請求。另一方面，ISAPI 篩選器還包含可以對 IIS 引發的事件進行響應的代碼。ISAPI 篩選器可以截取甚至修改傳入和傳出的數據。ISAPI 篩選器可以應用于很多方面，包括：

• 身份驗證和授權。
• 記錄和監視。
• HTTP 壓縮。
• URL 重寫。

雖然 ISAPI 篩選器可用于執行 URL 重寫，但本文將討論如何使用 ASP.NET 實現 URL 重寫。不過，我們將對使用 ISAPI 篩選器與使用 ASP.NET 中的技術實現 URL 重寫進行權衡。
請求進入 ASP.NET 引擎時將會發生什么情況在 ASP.NET 之前，需要使用 ISAPI 篩選器來實現 IIS Web 服務器上的 URL 重寫。由于 ASP.NET 引擎與 IIS 非常相似，因此可以使用 ASP.NET 進行 URL 重寫。存在相似之處的原因在于 ASP.NET 引擎可以實現以下功能：

• 在處理請求時可以引發事件。
• 允許任意數量的 HTTP 模塊處理所引發的事件，這與 IIS 的 ISAPI 篩選器相似。
• 將呈現被請求資源這項任務委托給 HTTP 處理程序，該處理程序與 IIS 的 ISAPI 擴展相似。

與 IIS 一樣，ASP.NET 引擎在請求的有效期內將會觸發事件，通過發信號來表示其處理過程從一個狀態改變為了另一個狀態。例如，當 ASP.NET 引擎首次響應請求時，BeginRequest 事件將被觸發。接下來觸發的是 AuthenticateRequest 事件，該事件在已建立用戶標識時出現。（此外，還有大量的其他事件：AuthorizeRequest、ResolveRequestCache 和 EndRequest，等等。這些事件屬于 System.Web.HttpApplication 類；有關詳細信息，請參閱位于以下網址的技術文檔：HttpApplication Class Overview。）
正如上一部分所討論的，可以創建 ISAPI 篩選器以響應 IIS 引發的事件。同樣，ASP.NET 提供了 HTTP 模塊，該模塊可以響應由 ASP.NET 引擎引發的事件。可以將 ASP.NET Web 應用程序配置為具有多個 HTTP 模塊。對于由 ASP.NET 引擎處理的每個請求，將初始化每個已配置的 HTTP 模塊，并允許將事件處理程序綁定到處理請求期間所引發的事件。請注意，對每個請求均使用了許多內置 HTTP 模塊。其中的一個內置 HTTP 模塊是 FormsAuthenticationModule，該模塊首先檢查是否使用了窗體身份驗證，如果使用，將檢查是否對用戶進行了身份驗證。如果沒有使用，會自動將用戶重定向到指定的登錄頁面。
如上所述，通過使用 IIS，傳入請求將最終發送給 ISAPI 擴展，而 ISAPI 擴展的任務是返回特定請求的數據。例如，在請求傳統的 ASP 網頁時，IIS 將請求傳遞給 asp.dll ISAPI 擴展，該擴展的任務是返回被請求的 ASP 頁面的 HTML 標記。ASP.NET 引擎使用相似的方法。初始化 HTTP 模塊后，ASP.NET 引擎的下一項任務是確定應由哪個 HTTP 處理程序來處理請求。
所有通過 ASP.NET 引擎傳遞的請求最終都將到達 HTTP 處理程序或 HTTP 處理程序工廠（HTTP 處理程序工廠僅返回 HTTP 處理程序的實例，然后使用該實例來處理請求）。最終的 HTTP 處理程序將返回響應，即呈現被請求的資源。此響應將被發送回 IIS，然后 IIS 將響應返回給提出請求的用戶。
ASP.NET 包括許多內置的 HTTP 處理程序。例如，PageHandlerFactory 用于呈現 ASP.NET 網頁。WebServiceHandlerFactory 用于呈現 ASP.NET Web 服務的響應 SOAP 信封。TraceHandler 將向 trace.axd 呈現請求的 HTML 標記。
圖 2 描述了如何處理對 ASP.NET 資源的請求。首先，IIS 接收到請求，并將請求調度給 aspnet_isapi.dll。接下來，ASP.NET 引擎對已配置的 HTTP 模塊進行初始化。最后將調用正確的 HTTP 處理程序，并呈現被請求的資源，將所生成的標記返回給 IIS 和請求客戶端。

圖 2. IIS 和 ASP.NET 正在處理請求

轉載于:https://www.cnblogs.com/yssoft/articles/1488080.html

總結

以上是生活随笔為你收集整理的在ASP.NET中UrlRewrite的实现（能隐藏扩展名）之一的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。