IIS URL Rewriting 和 ASP.NET routing（下）

作者: LanceZhang 來源: 博客園發布時間: 2010-01-05 10:01 閱讀: 1709 次推薦: 0 原文鏈接 [收藏]

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

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

　　我們該如何選擇?

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

如果我們的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應用程序了。詳見此地。
如果我們是基于一個已有的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。