URL Rewrite(1):IIS與ASP.NET

 

摘要:簡單講解了URL Rewrite的知識:IIS與ASP.NET

  之前覺得這個話題已經被談濫了。URL Rewrite早已經被廣大開發人員所接受,網上關於URL Rewrite的組件和文章也層出不窮,但是總是讓我感覺意猶未盡,於是最終還是忍不住提筆寫了這系列文章。這些文章不會談論URL Rewrite的價值與意義,而只會談論純技術的內容。文章中也不會有詳盡地實現分析,而是結合了我的經驗,從應用角度來講解這個話題。您已經知道的,您還不知道的,別處已經講過的,或者還沒有講過的,希望這系列文章的“舊事重提”不會讓您覺得沉悶,並且能讓您瞭解ASP.NET中URL Rewrite的方方面面。如果您以後再遇到URL Rewrite方面的問題是能夠想到這幾篇文章,估計我做夢也會笑出聲來。

  要充分理解文章後面談到的話題,我們必須簡單的瞭解一下IIS與ASP.NET的通信過程。我在這裏講解的是IIS 6服務器。至於IIS 5和IIS 7,前者可以說已經被淘汰了,而後者的“經典模式”與IIS 6可謂如出一轍,而新的“管道模式”其實是講ASP.NET中的某些概念與IIS進行了深度集成。我相信,如果您瞭解了IIS 6和ASP.NET,在IIS 7的集成模式下也不會有任何問題。

  首先我們來看一幅簡單的示意圖,展示了IIS從收到Request開始,到返回Response整個過程中的幾個主要步驟:

  1. IIS收到請求。
  2. 選擇器根據URL的特點與IIS中的配置,選擇一個ISAPI用於處理該請求——現在自然會選擇ASP.NET ISAPI。
  3. ASP.NET執行引擎接收到請求,於是初始化數據(例如構建各種對象)。
  4. 開始觸發各種Pipeline事件,自然先從BeginRequest開始。
  5. 經過了多個Pipeline事件,ASP.NET根據配置爲當前請求選擇一個合適的Handler或HandlerFactory進行處理(當然特殊情況例外,例如已經在之前的事件中直接輸出結果並結束請求了)。
  6. 經過了Handler處理之後又經過幾個Pipeline事件,以EndRequest結束。
  7. 輸出Response。

  在一個ASP.NET應用中如果要進行URL Rewrite,那麼一般就是在BeginRequest事件中調用HttpContext的RewritePath方法,將該請求重新“定位”至一個目標URL。例如我們就可以在Global.asax中重寫Application_BeginRequest方法來實現這一點:

  之所以在BeginRequest中進行Rewrite,是因爲這個事件是在所有Pipeline事件中最早被觸發的。在這時進行了重新“定位”之後,當前HttpContext中的一些屬性也就發生了相應的變化(例如HttpContext.Request.Path)。這樣,接下來的Pipeline事件的處理程序邏輯就會受到影響。例如在需要根據目錄進行權限判斷時,就會使用“定位”後的路徑,而不是ASP.NET所收到的請求。自然最“顯著”的變化就是對Handler的選擇,例如上例,我們把請求重新定位至“CustomerList.aspx”文件,這樣ASP.NET引擎就會選擇*.aspx所對應的System.Web.UI.PageHandlerFactory類對請求進行處理。

public class Global : System.Web.HttpApplication
{
    protected void Application_BeginRequest(object sender, EventArgs e)
    {
        HttpContext context = HttpContext.Current;
 
        if (context.Request.Path.Equals("/Customers",
            StringComparison.InvariantCultureIgnoreCase))
        {
            context.RewritePath("~/CustomerList.aspx");
        }
    }
}

  最後插句提外話,有兩個概念需要區分開來,那就是“ASP.NET Pipeline”與“Web Forms”。兩者都是ASP.NET裏的重要模型,但是差別還是非常大的:

  • ASP.NET Pipeline:作爲每個ASP.NET應用所接受到的請求來說,都會經過這個“管道”進行處理。這是一個ASP.NET級別的模型。
  • Web Forms:在ASP.NET Pipeline的執行過程中,其中有一個步驟是選擇一個合適的Handler(或HandlerFactory)來處理請求。如果是aspx頁面,ASP.NET就會選擇System.Web.UI.PageHandlerFactory類,在這個類中才最終形成了WebForms模型。

  其實上面這句話的“形成”二字可能也不太確切。因爲Web Forms可能應該是一個可以獨立使用的執行引擎和模型,而System.Web.UI.PageHandlerFactory中也只是利用了這個模型而已。我們在編寫ASP.NET應用時,完全可以根據我們的需要,在其他地方使用這個模型。例如在《技巧:使用User Control做HTML生成》一文中,我們就在一個Generic Handler中把ascx當作模板來生成內容。

 

 

原:http://kb.cnblogs.com/page/44420/ (博客園知識庫)

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章