IIS URL Rewriting 和 ASP.NET routing（下）

在IIS URL Rewriting 和 ASP.NET routing（上）中，我們針對IIS URL Rewriting 和 ASP.NET routing的理念和功能分別進行分析並進行對比，在清楚了這些基本原理和異同之後，我們該如何在應用中挑選合適的URL最佳化方案呢？在本文中，我們將對此進行探討分析，並例舉幾種兩者協同應用的案例。

本文翻譯自IIS官方網站，針對國內慣用的術語進行了部分調整。

我們該如何選擇?

首先，如果我們的Web應用程式有任何除了ASP.NET之外的動態網頁技術，那麼選擇是絕對明顯的：用IIS URL重寫模組（IIS URL-rewrite module）。否則的話，主要判斷規則如下：

1. 如果我們的ASP.NET Web應用程式使用了ASP.NET MVC 或者 ASP.NET Dynamic Data 技術的話，請使用ASP.NET路由。我們的應用程式URL最佳化過程將從原生支援中獲益（ASP.NET MVC 和ASP.NET Dynamic Data直接包含ASP.NET Routing）。早期的ASP.NET 路由不支援WebForm，而目前的版本已經支援標準的Web Form應用程式了。詳見此地。
2. 如果我們是基於一個已有的ASP.NET網站，而希望盡量不去更改它的話，請使用URL重寫模組。因為URL重寫模組能夠在不更改現有程式的基礎上對網站提供“方便使用”“搜尋引擎友好”的URL。同樣，它也允許我們建立重新導向規則，用來重新導向搜素引擎的爬蟲到新的URL去。

然而在實踐中這兩種技術並不是只能選擇一個，他們往往還可以相輔相成。在接下來的章節中，我們將概述幾個協同使用ASP.NET路由和URL重寫模組的案例。

為網站強制實施標準的URL

舉個例子，比如我們想強制使用http://www.mysite.com/home/about 來替代 http://mysite.com/Home/About。 當用戶端請求一個不符合標準格式的URL時，用戶端獎盃跳轉到一個符合標準格式的URL。在這種情況下，我們可以使用URL重寫模組來強制URL跳轉，而使用ASP.NET 路由來選擇一個handler來處理所請求的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>

提供來自其它網站或其它伺服器上的靜態內容

例如，我們的網站部署在多台伺服器上，而動態網頁面的內容部署在一台伺服器或一個網站上，而所有的靜態內容部署在另一台伺服器或另一個網站上。這時，我們可以使用URL重寫模組協同IIS Application Request Routing module 來將對鏡頭內容的請求轉到靜態內容伺服器（網站）上去，而由當前伺服器處理所有的動態網頁請求。這中環境下，ASP.NET 路由恰好只對所有的動態網頁內容起效，而不對靜態內容其效果。

下面的代碼展示了這個案例中可能用到的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路由來處理所有的動態ASP.NET頁面。

下面的代碼展示了這個案例中可能用到的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的路由處理，如此來減少伺服器的負載。

下面的例子展示了如何配置URL重寫規則，來阻止一個指定的網站爬蟲。可以根據指定的user-agent HTTP頭或者IP地址來進行阻止：

<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更好的整合，以提供更強大的擴充性和可自訂性。

結論

IIS URL重寫和ASP.NET路由都能夠用於Web應用程式的URL最佳化處理，但ASP.NET路由可以看作是一種ASP.NET的最佳化解決方案，因此，它是web開發人員設計友好URL的應用程式時的好選擇。而IIS URL重寫模組是一個通用的URL處理機制，定位於多種技術情境，特別是它能夠讓web開發人員和網站管理員能夠在不改動程式碼的情況下最佳化URL。

相關文檔

• URL-rewrite module documentation and tutorials
• ASP.NET routing documentation
• ASP.NET MVC
• ASP.NET Dynamic Data

參考閱讀

• Using URL Rewrite Module
• Provide URL Rewriting Functionality
• Rule with Rewrite Map - rule template
• IIS URL Rewriting and ASP.NET routing