共用方式為


IIS URL 重寫和 ASP.NET 路由

作者: Ruslan Yakushev

隨著適用于 IIS 的 URL 重寫模組發行,以及將 ASP.NET 路由納入.NET Framework 4 中,ASP.NET 開發人員對於這兩項功能彼此的關聯性,以及何時應該使用其中一項或另一個功能,有許多問題。 本檔說明這兩種技術之間的差異,並提供 Web 開發人員關於何時使用 IIS URL 重寫和何時使用 ASP.NET 路由的指引。

從高階的觀點來看,這些技術似乎提供非常類似的功能,這兩者都可讓您的 Web 應用程式具有使用者易記和搜尋引擎易記的 URL。 不過,這兩種技術之間有基本差異,請務必瞭解以正確決定要用於 Web 應用程式的內容。 為了協助您瞭解這些差異,我們會先說明 IIS URL 重寫和 ASP.NET 路由的運作方式。

IIS URL 重寫

URL 重寫的基本概念不是新的概念。 它已在 Apache Web 服務器中引進約十年前。 因此,它已證明是網頁伺服器管理員和 Web 開發人員非常有用的工具。 許多裝載在 Apache 上的熱門應用程式現在依賴 URL 重寫來啟用「清除」URL 的支援。

URL 重寫的概念很簡單。 當用戶端針對特定 URL 將要求傳送至 Web 服務器時,URL 重寫模組會分析要求的 URL,並將它變更為相同伺服器上的不同 URL。 URL 重寫模組會在要求處理管線中提早執行,在網頁伺服器決定處理要求之前修改要求的 URL。 根據重寫的 URL 選擇的處理常式會處理要求,並產生傳回給網頁瀏覽器的回應。 要求用戶端永遠不會看到重寫的 URL;就用戶端而言,它已收到來自原始 URL 的回應。

就 IIS 架構而言,此程式會以下圖表示:

I I S U R L 重寫程式從 H T T P 要求到 H T T P 回應的圖表。

URL Rewrite 模組是一個原生程式碼模組,會插入要求處理管線的 [預先開始要求] 或 [開始要求] 階段,然後使用一組重寫規則來評估要求的 URL 路徑。 每個重寫規則都會分析 URL 路徑,如果符合所有規則條件,請將原始路徑變更為新的路徑。 評估所有規則之後,URL 重寫模組會產生最終的 URL 路徑,此路徑會透過 IIS 管線處理的其餘部分用於要求。 這表示 IIS 管線中的處理常式選取是根據 URL 重寫模組所產生的重寫 URL 來進行。

ASP.NET 路由

ASP.NET 路由是要求分派機制,可讓開發人員將特定 URL 與處理常式產生關聯,以處理對該 URL 提出的要求。 此關聯是藉由註冊定義要針對特定 URL 路徑叫用哪些處理常式的「路由」來完成。 當對 Web 服務器提出要求 ASP.NET 路由時,路由會在已註冊的路由清單中查閱要求的 URL 路徑。 如果找到路由,則會叫用該路由的對應處理常式來處理該要求。

就 IIS 和 ASP.NET 架構而言,此程式會以下圖表示:

使用 I H T T P 處理常式從要求到回應的 S P 點 NET 路由程式圖表。

ASP.NET 路由會實作為 Managed 程式碼模組,此模組會在 PostResolveRequestCache 事件 (PostResolveRequestCache 事件) (和 PostMapRequestHandler 事件) 插入 IIS 要求處理管線。 ASP.NET 路由設定為針對對 Web 應用程式提出的所有要求執行。

在 PostResolveRequestCache 事件期間,模組會查看路由表 (路由物件的集合,) 符合所要求 URL 路徑的路由。 如果找到相符專案,模組會取得對應至該路由的處理常式參考,並將參考儲存為目前 HTTP 內容的一部分。 處理常式可以是實作 System.Web.IHttpHandler 介面的任何.NET Framework物件。 如果找不到路由,則模組不會執行任何動作,而且 URL 會通過,而且通常會透過將它與磁片上的檔案比對,) 處理一般 (。

在 PostMapRequestHandler 事件期間,模組會檢查 HTTP 內容是否包含處理常式的任何資訊。 如果這樣做,ASP.NET 路由會使用資訊來設定目前 HTTP 內容的 Handler 屬性。 這可確保在執行處理常式階段期間,IIS 會執行路由模組所選取的處理常式。 如果未設定該資訊,則模組不會執行任何動作,而且 URL 會通過,讓 IIS 進行處理常式選取。

IIS URL 重寫和 ASP.NET 路由之間的差異

根據上述說明,IIS URL 重寫和 ASP.NET 路由之間有下列主要概念差異:

  1. URL 重寫是用來在 Web 服務器處理要求之前操作 URL 路徑。 URL 重寫模組不知道哪一個處理常式最終會處理重寫的 URL。 此外,實際的要求處理常式可能不知道 URL 已重寫。
  2. ASP.NET 路由可用來根據要求的 URL 路徑,將要求分派至處理常式。 相對於 URL 重寫,路由模組知道處理常式,並選取應該為要求 URL 產生回應的處理常式。 您可以將 ASP.NET 路由視為進階處理常式對應機制。

除了這些概念差異之外,IIS URL 重寫和 ASP.NET 路由之間還有下列功能差異:

  1. IIS URL 重寫模組可以搭配任何類型的 Web 應用程式使用,其中包括 ASP.NET、PHP、ASP 和靜態檔案。 ASP.NET 路由只能與以.NET Framework為基礎的 Web 應用程式搭配使用。
  2. 不論整合式或傳統 IIS 管線模式是否用於應用程式集區,IIS URL 重寫模組的運作方式都相同。 針對 ASP.NET 路由,最好使用整合式管線模式。 ASP.NET 路由可在傳統模式中運作,但在此情況下,應用程式 URL 必須包含副檔名,或應用程式必須設定為在 IIS 中使用 「*」 處理常式對應。
  3. IIS URL 重寫模組可以根據功能變數名稱、HTTP 標頭和伺服器變數做出重寫決策。 根據預設,ASP.NET 路由僅適用于 URL 路徑和HTTP-Method標頭。
  4. 除了重寫之外,URL 重寫模組還可以執行 HTTP 重新導向、發出自訂狀態碼,以及中止要求。 ASP.NET 路由不會執行這些工作。
  5. URL 重寫模組在其目前版本中無法擴充。 ASP.NET 路由完全可擴充且可自訂。

您應該使用哪一個選項?

如果您需要選擇技術來啟用 Web 應用程式的清除 URL,這項資訊是什麼意思? 在本節中,我們會說明如何進行這項選擇。

如果您的 Web 應用程式是使用 ASP.NET 以外的任何專案來建置,請使用 IIS URL 重寫模組。 否則,規則如下:

  1. 如果您要開發使用 ASP.NET MVCASP.NET Dynamic Data 技術的新 ASP.NET Web 應用程式,請使用 ASP.NET 路由。 您的應用程式將受益于原生支援清除 URL,包括產生網頁中連結的全新 URL。 請注意,ASP.NET 路由尚不支援標準Web Form應用程式,但未來仍計畫支援它。
  2. 如果您已經有舊版 ASP.NET Web 應用程式,而且不想變更它,請使用 URL 重寫模組。 URL 重寫模組可讓您將搜尋引擎易記 URL 轉譯為應用程式目前使用的格式。 此外,它可讓您建立可用來將搜尋引擎編目程式重新導向至清除 URL 的重新導向規則。

不過,在實務上,選擇不一定是/或。 這些技術可以一起使用,並可彼此互補。 在下列各節中,我們會概述一些案例,您可以在其中同時使用 ASP.NET 路由和 IIS URL 重寫。

為您的應用程式強制執行標準 URL。
您應該強制使用 http://www.mysite.com/home/abouthttp://mysite.com/Home/About 而不是 。 當 Web 用戶端要求不符合所需格式的 URL 時,用戶端會重新導向至標準 URL。 在此案例中,您可以使用 URL 重寫模組來強制執行標準 URL 並執行重新導向,並使用 ASP.NET 路由來選取處理要求的 URL 路徑的處理常式。

下列範例顯示可用於此案例的 URL 重寫規則:

<rewrite>
    <rules>
        <rule name="Enforce canonical hostname" stopProcessing="true">
            <match url="(.*)" />
            <conditions>
                <add input="{HTTP_HOST}" negate="true" pattern="^www\.mysite\.com$" />
            </conditions>
            <action type="Redirect" url="http://www.mysite.com/{R:1}" redirectType="Permanent" />
        </rule>
    </rules>
</rewrite>

從不同的網站或伺服器提供靜態內容。
您的 Web 應用程式會部署在多部伺服器上,讓動態 Web 內容位於一個網站或伺服器上,而所有靜態內容都位於不同的網站或伺服器上。 您可以使用 URL 重寫模組搭配 IIS 應用程式要求路由模組 ,將靜態檔案的所有要求轉送至不同的伺服器,同時提供目前伺服器中動態網頁的所有要求。 如此一來,ASP.NET 路由只會用於動態 Web 內容,而且不會評估靜態內容的任何 URL。

下列範例顯示可用於此案例的 URL 重寫規則:

<rewrite>
    <rules>
        <rule name="Forward to static file server">
            <match url="^.+\.(?:jpg|bmp|gif)$" />
            <action type="Rewrite" url="http://static_file_server/{R:0}" />
        </rule>
    </rules>
</rewrite>

靜態內容管理
當您的靜態檔案或資料夾移至新位置時,您仍可支援舊 URL,因為回溯相容性的原因。 事實上,您可能不希望網站訪客知道檔案或資料夾已移動。 在此情況下,您可以使用 URL 重寫模組來重寫靜態檔案的路徑,而動態 ASP.NET 網頁的所有 URL 都會由路由模組處理。

下列範例顯示可用於此案例的 URL 重寫規則:

<rewrite>
    <rules>
        <rule name="Rewrite to new folder">
            <match url="^Images/(.+)$" />
            <action type="Rewrite" url="NewImages/{R:1}" />
        </rule>
    </rules>
</rewrite>

要求封鎖
URL 重寫模組可用來根據各種準則封鎖特定要求。 例如,您可以防止特定網站編目程式存取您網站上的特定 URL 路徑。 如此一來,禁止的要求甚至不會進入 ASP.NET 路由器,因而降低 Web 服務器上的負載。

下列範例顯示 URL 重寫規則,可用來封鎖不必要的網站編目程式。 請注意,系統會根據使用者代理程式 HTTP 標頭或用戶端的 IP 位址,封鎖特定 URL 路徑的要求:

<rewrite>
    <rules>
        <rule name="Block SomeRobot" stopProcessing="true">
            <match url="^folder1/folder2" />
            <conditions logicalGrouping="MatchAny">
                <add input="{USER_AGENT}" pattern="SomeRobot" />
                <add input="{REMOTE_ADDR}" pattern="201\.45\.33\.[0-5]" />
            </conditions>
            <action type="AbortRequest" />
        </rule>
    </rules>
</rewrite>

未來方向

雖然 IIS URL 重寫和 ASP.NET 路由有一些功能重迭,但它們可解決每個技術特有的案例。 因此,這兩種技術會繼續存在,並隨著 IIS 中的獨立元件演進,並可能更緊密地整合它們。 例如,ASP.NET 路由可以利用 URL 重寫模組所提供的一些豐富工具。 URL 重寫模組可以更妥善地與 ASP.NET 整合,以提供自訂 URL 重寫邏輯的擴充性。

結論

IIS URL 重寫或 ASP.NET 路由可用來實作 Web 應用程式的 URL 操作案例。 ASP.NET 路由是針對 ASP.NET 優化的解決方案,因此對於從頭開始設計其 ASP.NET 應用程式的 Web 開發人員來說,最好有一個全新的 URL 結構。 IIS URL 重寫是一般 URL 操作機制,可解決許多案例。 特別是,Web 開發人員和 Web 服務器/網站管理員可以使用它,以啟用現有 Web 應用程式的清除 URL,而不需修改應用程式程式碼。