引言 讓我們花點時間來看一下網站上的一些 URL
您是否發現一些類似於 x?EmpID=
&type=summary 的 URL?或者
您可能將一系列網頁從一個目錄或網站移動到另一個目錄或網站
結果導致已將舊 URL 用作書簽的訪問者斷開鏈接
在本文中
我們將了解如何通過將 x?EmpID=
&type=summary 替換為類似於 的網址
使用 URL 重寫將那些冗長的 URL 縮寫為富有意義且容易記憶的 URL
我們還將了解如何將 URL 重寫用於創建智能
錯誤
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 均為
則用戶可以訪問以下網址
x?CategoryID=
創建具有此類 URL 的網站有兩點不足
首先
從最終用戶的角度考慮
URL x?CategoryID=
比較雜亂
可用性專家 Jakob Neilsen建議遵循以下標准來選擇 URL
; 簡短
; 易於鍵入
; 可以看出站點的結構
;
可刪節
允許用戶通過刪除 URL 的組成部分來浏覽站點
我還要增加一條標准
即
URL 應該便於記憶
URL x?CategoryID=
不符合 Neilsen 的任何標准
也不容易記住
要求用戶鍵入查詢字符串值將使 URL 的鍵入變得非常困難
並且只有了解查詢字符串參數的用途及其名稱/值對結構的富有經驗的 Web 開發人員才能夠對 URL 進行
刪節
較好的方法是允許使用切合實際且容易記憶的 URL
如
只要看一眼 URL
您便可以推斷出將要顯示的內容
有關 Widget 的信息
此 URL 也很容易記住和共享
我可以告訴我的同事
請查看 /products/Widgets
她可能無需再次問我 URL 是什麼即可打開該頁面
(嘗試一下
您只需說出
頁面
即可!)此 URL 還將顯示出來
並且應該是
可刪節
的
也就是說
如果用戶刪去 URL 的末端
鍵入
他們應該看到所有產品的列表
或者至少應該看到他們可以查看的所有類別的產品列表
注意
要獲得
可刪節
URL 的最好示例
可考慮使用由許多 blog 引擎生成的 URL
要查看
年
月
日的帖子
用戶可以訪問諸如 的 URL
如果該 URL 被刪節為
用戶將看到
年
月的所有帖子
將該 URL 進一步刪節為 將顯示
年的所有帖子
除了簡化 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 擴展的映射關系
圖
顯示了 Internet Information Services 管理工具的
應用程序配置
對話框
請注意
與 ASP
NET 有關的擴展名(
aspx
ascx
config
asmx
rem
cs
vb 及其他)均已映射到 aspnet_isapi
dll ISAPI 擴展
圖 已配置的文件擴展名映射 討論 IIS 如何管理傳入請求稍稍超出了本文范圍
但是可以在 Michele Leroux Bustamante 的文章 Inside IIS and ASP
NET 中找到對此內容的深入討論
ASP
NET 引擎僅處理那些擴展名已明確映射至 IIS 中的 aspnet_isapi
dll 的傳入 Web 請求
了解這一點非常重要
<b>使用 ISAPI 篩選器檢查請求</b>
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 處理
From:http://tw.wingwit.com/Article/program/net/201311/12477.html