URL Rewrite Module Configuration Reference (URL Rewrite Module 組態參考)

Ruslan Yakushev

本文提供 URL 重寫模組的概觀,並說明模組所使用的設定概念。

功能概觀

URL Rewrite Module 會將要求 URL 重寫為簡單、方便使用者且搜尋引擎易記的位址,這些位址會顯示給使用者或 Web 應用程式中。 URL 重寫會使用定義的規則來評估,然後將要求 URL 對應至規則中定義的位址,再由 IIS Web 伺服器處理。 您可以定義 URL 重寫邏輯,其中包含正規表示式和通配符,而且規則可以根據要求 URL、HTTP 標頭和伺服器變數套用。 雖然模組的主要目的是將要求 URL 重寫為更易記的 URL,但您也可以使用模組來定義執行重新導向、傳送自定義回應或中止要求的規則。

重寫規則概觀

重寫規則會定義要比較或比對要求 URL 的邏輯,以及在比較成功時該怎麼辦。

重寫規則包含下列部分:

  • Pattern – 規則模式可用來指定正則表示式或用來比對 URL 字串的通配符模式。
  • 條件 – 選擇性條件 集合可用來指定 URL 字串符合規則模式時要執行的其他邏輯作業。 在條件中,您可以檢查 HTTP 標頭或伺服器變數的特定值,或確認所要求的 URL 是否對應至實體文件系統上的檔案或目錄。
  • 動作 – 動作是用來指定 URL 字串符合規則模式和符合所有規則條件時要執行的動作。

重寫規則範圍

重寫規則可以在兩個不同的集合中定義:

  • <globalRules> – 此集合中的規則只能在伺服器層級上定義。 全域規則可用來定義全伺服器 URL 重寫邏輯。 這些規則是在 ApplicationHost.config 檔案中定義,而且無法在任何較低的組態層級上覆寫或停用這些規則。 全域規則一律會在絕對 URL 的路徑上運作(也就是沒有伺服器名稱的要求 URI)。 這些規則會在 IIS 要求處理管線中早期評估(PreBeginRequest 事件)。
  • <rules> – 此集合中的規則稱為分散式規則,而且可以在組態階層中的任何層級上定義規則。 分散式規則可用來定義特定組態範圍特定的 URL 重寫邏輯。 您可以使用 Web.config 檔案,或使用 <location> ApplicationHost.config 或 Web.config 檔案內的捲標,在任何組態層級新增這種類型的規則。 分散式規則會在 URL 路徑上運作,相對於定義這些規則的 Web.config 檔案位置。 在標記內 <location> 定義分散式規則的情況下,它們會在URL路徑上運作,相對於該 <location> 標記所指定的路徑。 這些規則會在 IIS 管線中的 BeginRequest 事件上進行評估。

規則評估

IIS 中的每個組態層級都可以定義零或多個重寫規則。 規則會以指定的相同順序進行評估。 URL Rewrite Module 會使用下列演演算法來處理規則集:

  1. 首先,URL 會與規則的模式進行比對。 如果不符合,URL 重寫模組會立即停止處理該規則,然後繼續下一個規則。
  2. 如果模式相符且規則沒有任何條件,URL Rewrite Module 會執行為此規則指定的動作,然後移至下一個規則,其中會使用替代的 URL 做為該規則的輸入。
  3. 如果模式符合,而且規則有條件,則 URL Rewrite Module 會評估條件。 如果評估成功,則會執行指定的規則動作,然後使用重寫的URL做為後續規則的輸入

規則可能會 開啟 StopProcessing 旗標。 執行規則動作(亦即符合規則)並開啟此旗標時,表示不會再處理任何後續的規則,並將要求傳遞至 IIS 要求管線。 根據預設,此旗標會關閉。

規則繼承

如果規則是在多個組態層級上定義,URL Rewrite Module 會依下列順序評估規則:

  1. 評估所有全域規則。
  2. 評估規則集,其中包含來自父組態層級的分散式規則,以及來自目前組態層級的規則。 評估是以父對子順序執行,這表示先評估父規則,最後一次評估最後一個子層級上定義的規則。

保留原始 URL

URL 重寫模組會在下列伺服器變數中保留原始要求的 URL 路徑:

  • HTTP_X_ORIGINAL_URL – 此伺服器變數包含已譯碼格式的原始 URL;
  • UNENCODED_URL – 此伺服器變數包含與 Web 用戶端要求的原始 URL 完全相同,並保留所有原始編碼。

從重寫規則存取 URL 元件

請務必瞭解如何從重寫規則存取 URL 字串的某些部分。

針對此格式的 HTTP URL:HTTP(s)://<host>:<port>/<path>?<querystring>

  • 路徑<>會根據規則的模式進行比對。
  • <查詢字串>可在稱為 QUERY_STRING 的伺服器變數中使用,而且可以使用規則內的條件來存取。
  • 主機<>可在伺服器變數中取得HTTP_HOST,而且可以使用規則內的條件來存取。
  • 埠<>可在伺服器變數中取得SERVER_PORT,而且可以使用規則內的條件來存取。
  • 伺服器變數SERVER_PORT_SECURE和 HTTPS 可用來判斷是否使用安全連線。 您可以使用規則內的條件來存取這些伺服器變數。
  • 伺服器變數REQUEST_URI可用來存取整個要求的 URL 路徑,包括查詢字串。

例如,如果已針對此 URL 提出要求: http://www.mysite.com/content/default.aspx?tabid=2&subtabid=3,並在網站層級定義重寫規則,則:

  • 規則模式會取得 URL 字串 content/default.aspx 做為輸入。
  • QUERY_STRING伺服器變數包含 tabid=2&subtabid=3
  • HTTP_HOST伺服器變數包含 www.mysite.com
  • SERVER_PORT伺服器變數包含 80
  • SERVER_PORT_SECURE伺服器變數包含 0 ,而 HTTPS 則包含 OFF
  • REQUEST_URI伺服器變數包含 /content/default.aspx?tabid=2&subtabid=3
  • PATH_INFO伺服器變數包含 /content/default.aspx

請注意,傳遞至分散式規則的輸入URL字串一律與定義規則的Web.config檔案位置相對。 例如,如果對 http://www.mysite.com/content/default.aspx?tabid=2&subtabid=3提出 要求,且重寫規則定義於 /content 目錄中,則規則會取得此 URL 字串 default.aspx 做為輸入。

重寫規則組態

規則模式

重寫規則模式可用來指定比較目前 URL 路徑的模式。 目前在此內容中,表示套用規則時URL路徑的值。 如果目前規則之前有任何規則,它們可能已符合原始要求的URL並加以修改。 針對模式評估的 URL 字串不包含查詢字串。 若要在規則評估中包含查詢字串,您可以在規則的條件中使用QUERY_STRING伺服器變數。 如需詳細資訊,請參閱

在重寫規則的相符>專案內<指定模式。

規則模式語法

您可以使用規則的 patternSyntax 屬性來指定規則模式語法。 這個屬性可以設定為下列其中一個選項:

ECMAScript – Perl 相容 (ECMAScript 標準相容) 正則表示式語法。 這是任何規則的預設選項。 這是模式格式的範例:“^([_0-9a-zA-Z-]+/)?(wp-.*)”

通配符 – IIS HTTP 重新導向模組中使用的通配符語法。 以下是此格式模式的範例:“/Scripts/*_in.???”,其中星號 (“*”) 表示“比對任何數目的任何字元,並在反向參考中擷取它們”,而 “?” 表示完全符合一個字符(沒有建立反向參考)。

patternSyntax 屬性的範圍是每個規則,這表示它會套用至目前規則的模式,以及該規則條件內使用的所有模式。

規則模式屬性

模式可以使用 match> 元素的<否定屬性來否定。 使用此屬性時,只有當目前的 URL 不符合指定的模式時,才會執行規則動作。

根據預設,會使用不區分大小寫的模式比對。 若要啟用區分大小寫,您可以使用規則相符>專案的 ignoreCase 屬性<。

規則條件

規則條件允許定義規則評估的其他邏輯,此邏輯可以根據目前URL字串以外的輸入。 任何規則都可以有零個或多個條件。 規則條件會在規則模式比對成功之後進行評估。

條件定義於重寫規則的條件集合內<>。 此集合具有稱為 logicalGrouping 的屬性,可控制條件的評估方式。 如果規則有條件,則只有在符合規則模式且:

  • 所有條件都評估為 true,前提是已使用logicalGrouping=“MatchAll”。
  • 如果 已使用logicalGrouping=“MatchAny” ,則至少有一個條件評估為 true。

條件是藉由指定下列屬性來定義:

  • 輸入字串
  • 比對類型

條件輸入會指定要作為條件評估輸入的專案。 條件輸入是任意字串,可包含伺服器變數和先前條件模式和/或規則模式的反向參考。

比對類型可以是下列三個選項之一:

  • IsFile – 此比對類型可用來判斷輸入字串是否包含檔案系統上檔案的實體路徑。 如果未指定條件輸入字串,URL Rewrite Module 會使用所要求檔案的實體路徑做為條件輸入的預設值。 此比對類型只能用於分散式規則。

  • IsDirectory – 此比對類型可用來判斷輸入字串是否包含文件系統上目錄的實體路徑。 如果未指定條件輸入字串,URL Rewrite Module 會使用所要求檔案的實體路徑做為條件輸入的預設值。 此比對類型只能用於分散式規則。

  • 模式 – 此比對類型可用來表示任意輸入字串與正則表示式模式相符的條件。 您可以使用正規表示式語法或使用通配符語法來指定條件模式。 在條件中使用的模式類型取決於針對此條件所屬規則所定義的 patternSyntax 旗標值。 此條件類型有兩個控制模式比對的相關屬性:

    • pattern – 使用這個屬性來指定實際的模式。
    • ignoreCase – 使用這個屬性來控制條件的模式比對是否應該區分大小寫或區分大小寫。

此外,可以使用負屬性來否定條件評估的結果。 這可用來指定條件,以檢查要求的URL是否為檔案,如下列範例所示:

<add input="{REQUEST_FILENAME}" matchType="isFile" negate="true">

規則動作

當目前的 URL 符合規則模式和條件評估成功時,就會執行重寫規則動作(視規則組態而定,符合所有條件或符合任何一或多個條件)。 有數種類型的動作可用,而且動作>組態專案的 type 屬性<可用來指定規則執行的動作。 下列各節說明與特定動作類型相關的不同動作類型和組態選項。

重寫動作

重寫動作會將目前的 URL 字串取代為替代字串。 替代字串必須一律指定 URL 路徑(例如 contoso/test/default.aspx)。 請注意,IIS 不支援在檔案系統上包含實體路徑的替代專案(例如 C:\inetpub\wwwroot, 。

重寫動作具有下列組態選項:

  • url – 這是重寫目前 URL 時要使用的替代字串。 替代 URL 是字串值,可包含下列專案:

    • 條件和規則模式的回溯參考。 (如需詳細資訊,請參閱如何使用反向參考一節。
    • 伺服器變數。 (如需詳細資訊,請參閱如何使用伺服器變數一節。
  • appendQueryString – 指定在替代期間是否保留來自目前 URL 的查詢字串。 根據預設,如果未指定 appendQueryString 旗標的值,則會假設為 TRUE。 這表示原始 URL 中的查詢字串會附加至替代的 URL。

重新導向動作

重新導向動作會指示 URL 重寫模組將重新導向回應傳送回用戶端。 重新導向狀態代碼 (3xx) 可以指定為此動作的參數。 回應的 [ 位置] 欄位包含規則中指定的替代字串。

重新導向規則的替代 URL 可以用下列其中一種形式指定:

  • 相對 URL 路徑 – contoso/test/default.aspx
  • 絕對 URI – https://example.com/contoso/test/default.aspx

重新導向動作的使用 意指在執行重新 導向之後,不會評估目前URL的後續規則。

重新 導向 動作具有下列組態選項:

  • url – 使用替代字串作為重新導向 URL。 替代網址是可包含下列項目的字串:

    • 條件和規則模式的回溯參考。 (如需詳細資訊,請參閱如何使用反向參考一節。
    • 伺服器變數。 (如需詳細資訊,請參閱如何使用伺服器變數一節。
  • appendQueryString – 指定是否應該在替代期間保留來自目前 URL 的查詢字串。 根據預設,如果未 指定 AppendQueryString 旗標,則會假設為 TRUE。 這表示原始 URL 中的查詢字串會附加至替代的 URL。

  • redirectType – 指定要在重新導向期間使用的狀態代碼:

    • 301 – 永久
    • 302 – 找到
    • 303 – 請參閱其他
    • 307 – 暫時性

CustomResponse 動作

CustomResponse 動作會使用使用者指定的狀態代碼、子程式代碼和原因,讓 URL Rewrite 模組回應 HTTP 用戶端。 使用 CustomResponse 宏指令表示在執行此動作之後,不會評估目前 URL 的後續規則。

CustomResponse 動作具有下列組態選項:

  • statusCode – 指定要用來回應用戶端的狀態代碼。
  • subStatusCode – 指定要用於回應用戶端的子狀態程序代碼。
  • statusReason – 指定要與狀態代碼搭配使用的原因片語。
  • statusDescription – 指定要放入響應主體中的一行描述。

AbortRequest 宏指令

AbortRequest 動作會導致 URL Rewrite Module 卸除目前要求的 HTTP 連線。 動作沒有任何參數。 使用此動作表示在執行此動作之後,不會評估目前URL的後續規則。

無動作

None 宏指令用來指定不會執行任何動作。

在重寫規則中使用伺服器變數

伺服器變數提供有關目前 HTTP 要求的其他資訊。 您可以使用這項資訊來進行重寫決策,或撰寫重寫的 URL。 您可以在重寫規則內的下列位置參考伺服器變數:

  • 在條件輸入字串中

  • 在規則替代字串中,具體來說:

    • 重寫和重新導向動作的url 屬性
    • CustomResponse 動作的 statusLineresponseLine

您可以使用 {VARIABLE_NAME} 語法來參考伺服器變數。 例如,下列條件會使用 QUERY_STRING 伺服器變數:

<add input="{QUERY_STRING}" pattern="id=([0-9]+)" />

伺服器變數也可以用來存取來自目前要求的 HTTP 標頭。 目前要求提供的任何 HTTP 標頭都會以伺服器變數表示,該伺服器變數具有根據此命名慣例所產生的名稱:

  1. HTTP 標頭名稱中的所有破折號 (“-”) 符號都會轉換成底線符號 (“_” )。
  2. HTTP 標頭名稱中的所有字母都會轉換成大寫字母。
  3. “HTTP_” 前置詞會新增至標頭名稱。

例如,若要從重寫規則存取 HTTP 標頭 「user-agent」,您可以使用 {HTTP_USER_AGENT} 伺服器變數。

在重寫規則中使用反向參考

規則或條件輸入的部分可以在反向參考中擷取。 然後,這些可用來在規則動作內建構替代 URL,或建構規則條件的輸入字串。

背參考會以不同的方式產生,視規則使用哪種模式語法而定。 使用ECMAScript模式語法時,可以藉由將括弧放在必須擷取反向參考之模式的一部分來建立反向參考。 例如,模式 ([0-9]+)/([a-z]+).html會從這個要求的 URL 擷取 07文章:07/article.html。 使用「通配符」模式語法時,在模式中使用星號符號 \ 時,一律會建立反向參考。 當模式中使用 “?” 時,不會建立任何反向參考。 例如,模式 */*.html 會從這個要求的 URL 擷取 contoso ,並在 反向參考中測試contoso/test.html

不論使用哪一種模式語法來擷取它們,反向參考的使用方式都相同。 回溯參考可用於重寫規則內的下列位置:

  • 在條件中輸入字串

  • 在規則動作中,具體來說:

    • 重寫和重新導向動作的url 屬性
    • CustomResponse 動作的 statusLineresponseLine
  • 在重寫對應的關鍵參數中

條件模式的反向參考是由 {C:N} 識別,其中 N 是 0 到 9。 規則模式的反向參考是由 {R:N} 識別,其中 N 從 0 到 9。 請注意,針對這兩種類型的反向參考,{R:0} 和 {C:0}都會包含相符的字串。

例如,在此模式中:

^(www\.)(.*)$

針對字串: www.foo.com 後端參考會編製索引,如下所示:

{C:0} - www.foo.com
{C:1} - www.
{C:2} - foo.com

在規則動作中,您可以使用規則模式的反向參考,以及該規則的最後一個相符條件。 在條件輸入字串內,您可以使用規則模式和先前相符條件的反向參考。

下列規則範例示範如何建立和參考反向參考:

<rule name="Rewrite subdomain">
 <match url="^(.+)" /> <!-- rule back-reference is captured here -->
 <conditions>
  <add input="{HTTP_HOST}" type="Pattern" pattern="^([^.]+)\.mysite\.com$" /> <!-- condition back-reference is captured here -->
 </conditions>
 <action type="Rewrite" url="{C:1}/{R:1}" /> <!-- rewrite action uses back-references to condition and to rule when rewriting the url -->
</rule>

與 IIS 輸出快取的互動

URL Rewrite Module 會控制 IIS 輸出快取行為,以便:

  1. 以最佳方式利用核心模式和使用者模式輸出快取來重寫 URL 的回應,進而改善使用 URL 重寫模組的 Web 應用程式效能。
  2. 防止快取回應,因為 URL 重寫而違反快取邏輯時。

模組會藉由改變特定快取屬性或完全停用快取來控制輸出快取。 如果 IIS 組態或 IIS 管線中任何其他模組已停用輸出快取,模組就無法啟用輸出快取。 輸出快取的控制如下:

  1. 模組一律會設定使用者模式快取設定 varyByHeader=“HTTP_X_ORIGINAL_URL”。 這可確保啟用使用者模式快取時,模組會考慮原始 URL 來建構快取專案的密鑰。

  2. 如果重寫規則集使用伺服器變數,其值在程序整個生命週期中都是常數,或衍生自要求的 URL,則規則集會被視為安全的輸出快取。 這表示 URL 重寫模組不會以設定 varyByHeader 以外的任何方式改變現有的快取原則,如步驟 1 中所述。

    在重寫規則中使用下列伺服器變數時,不會對輸出快取原則造成任何影響:

    • “CACHE_URL”
    • “DOCUMENT_ROOT”
    • “HTTP_URL”
    • “HTTP_HOST”
    • “PATH_INFO”
    • “PATH_TRANSLATED”
    • “QUERY_STRING”
    • “REQUEST_FILENAME”
    • “REQUEST_URI”
    • “SCRIPT_FILENAME”
    • “SCRIPT_NAME”
    • “SCRIPT_TRANSLATED”
    • “UNENCODED_URL”
    • “URL”
    • “URL_PATH_INFO”
    • “”APP_POOL_ID”
    • “APPL_MD_PATH”
    • “APPL_PHYSICAL_PATH”
    • “GATEWAY_INTERFACE”
    • “SERVER_SOFTWARE”
    • “SSI_EXEC_DISABLED”
  3. 如果重寫規則集使用上述清單中未提及的任何伺服器變數,則規則集會被視為不安全的輸出快取。 這表示 URL 重寫模組會停用所有要求的核心模式快取,無論要求 URL 是否已重寫。 此外,模組會藉由設定快取屬性 varyByValue 來變更使用者模式快取的快取原則,以包含規則集中使用之所有伺服器變數值的串連字串。

字串函數

有三個字串函式可用來變更重寫規則動作中的值,以及任何條件:

  • ToLower - 傳回轉換成小寫的輸入字串。
  • UrlEncode - 傳回轉換成 URL 編碼格式的輸入字串。 如果重寫規則中的替代 URL 包含特殊字元,例如非 ASCII 或 URI 不安全字元,則可以使用此函式。
  • UrlDecode - 譯碼 URL 編碼的輸入字串。 此函式可用來譯碼條件輸入,再將其與模式比對。

您可以使用下列語法叫用函式:

{function_name:any_string}

其中 「function_name」 位於下列 eof:“ToLower”、“UrlEncode”、“UrlDecode”。 “Any_string” 可以是使用伺服器變數或反向參考所建置的常值字串或字串串。 例如,以下是字串函式的有效調用:

{ToLower:DEFAULT.HTM}
{UrlDecode:{REQUEST_URI}}
{UrlEncode:{R:1}.aspx?p=[résumé]}

字串函式可用於重寫規則內的下列位置:

  • 在條件中輸入字串

  • 在規則替代字串中,具體來說:

    • 重寫和重新導向動作的url屬性
    • CustomResponse 動作的 statusLineresponseLine 屬性

使用 ToLower 函式的規則範例:

<rule name="Redirect to canonical url">
 <match url="^(.+)" /> <!-- rule back-reference is captured here -->
 <conditions>
  <!-- Check whether the requested domain is in canonical form -->
  <add input="{HTTP_HOST}" type="Pattern" pattern="^www\.mysite\.com$" negate="true" /> 
 </conditions>
 <!-- Redirect to canonical url and convert URL path to lowercase -->
 <action type="Redirect" url="http://www.mysite.com/{ToLower:{R:1}}" redirectType="Found" />
</rule>

使用 UrlEncode 函式的規則範例:

<rules>
   <rule name="UrlEncode example" stopProcessing="true">
   <match url="resume" />
   <action type="Rewrite" url="default.aspx?name={UrlEncode:résumé}"/>
</rule>

使用 UrlDecode 函式的規則範例:

<rules>
   <rule name="UrlDecode example">
      <match url="default.aspx" />
      <conditions>
         <add input="{UrlDecode:{QUERY_STRING}}" pattern="résumé" />
      </conditions>
      <action type="Rewrite" url="default.aspx?type=resume" />
   </rule>
</rules>

重寫地圖

重寫對應是任意的名稱/值組集合,可在重寫規則內用來在重寫期間產生替代 URL。 當您有一組大量的重寫規則,而且所有這些規則都使用靜態字串時,重寫對應特別有用(也就是沒有使用的模式比對時)。 在這些情況下,您可以不要定義一組大型的簡單重寫規則,而是將所有對應放入重寫對應中,做為輸入 URL 與替代 URL 之間的索引鍵和值。 然後,若要根據輸入 URL 查閱替代 URL,您將有一個參考重寫對應的重寫規則。

重寫對應會定義名稱/值組字串的具名集合,如下列範例所示:

<rewriteMap name="MyRewriteMap" defaultValue="">
  <add key="a.html" value="b.html" />
  <add key="c.aspx" value="d.aspx" />
  <add key="e.php" value="f.php" />
</rewriteMap>

重寫對應會以其名稱唯一識別,而且可以包含零個或多個索引鍵/值專案。 此外,重寫對應可以指定找不到索引鍵時要使用的預設值。 這是使用 defaultValue 屬性來控制。 根據預設,空字串會當做預設值使用。

除了檔案層級之外,任何組態層級上都可以有任意數目的重寫對應。 重寫對應位於重寫 地圖> 集合元素內<。

重寫對應是使用下列語法在重寫規則內參考的:

{RewriteMapName:Key}

其中 Key 參數可以是任何任意字串,而且可以包含規則或條件模式的反向參考。 例如,下列是重寫對應的有效用法:

{MyRewriteMap:contoso/{R:1}/test/{C:1}}
{MyRewriteMap:a.html}
{MyRewriteMap:{R:1}?{C:1}&contoso=test}

重寫地圖的參考會取代為使用重寫對應參考內傳遞做為參數的索引鍵所查閱的值。 如果找不到索引鍵,則會使用該重寫對應的預設值。

重寫對應可以在重寫規則內的下列位置中參考:

  • 在條件輸入字串中

  • 在規則替代字串中,具體來說:

    • 重寫和重新導向動作的url屬性
    • CustomResponse 動作的 statusLineresponseLine

範例 1:使用定義如下的重寫對應:

<rewrite>
 <rewriteMaps>
  <rewriteMap name="StaticRewrites" defaultValue="">
    <add key="/diagnostics" value="/default.aspx?tabid=2&amp;subtabid=29" />
    <add key="/webcasts" value="/default.aspx?tabid=2&amp;subtabid=24" />
    <add key="/php" value="/default.aspx?tabid=7116" />
  </rewriteMap>
 </rewriteMaps>
</rewrite>

並定義如下的重寫規則:

<rewrite>
 <rule name="Rewrite Rule">
  <match url=".*" />
  <conditions>
   <add input="{StaticRewrites:{REQUEST_URI}}" pattern="(.+)" />
  </conditions>
  <action type="Rewrite" url="{C:1}"/>
 </rule>
</rewrite>

要求的 URL /diagnostic 將會重寫為 /default.aspx?tabid=2&subtabid=29
要求的 URL /webcasts 將會重寫為 /default.aspx?tabid=2&subtabid=24
要求的 URL /php 將會重寫為 /default.aspx?tabid=7116
要求的 URL /default.aspx 將不會重寫,因為重寫對應不包含 key=“/default.aspx”的專案;因此重寫對應會傳回不符合條件模式的空字串,因此不會執行規則動作。

範例 2:重寫對應的定義如下:

<rewrite>
 <rewriteMaps>
  <rewriteMap name="StaticRedirects" defaultValue="">
    <add key="/default.aspx?tabid=2&amp;subtabid=29" value="/diagnostics" />
    <add key="/default.aspx?tabid=2&amp;subtabid=24" value="/webcasts" />
    <add key="/default.aspx?tabid=7116" value="/php" />
  </rewriteMap>
 </rewriteMaps>
</rewrite>

並定義如下的重寫規則:

<rewrite>
 <rule name="Redirect rule">
  <match url=".*" />
  <conditions>
   <add input="{StaticRedirects:{REQUEST_URI}}" pattern="(.+)" />
  </conditions>
  <action type="Redirect" url="http://www.contoso.com{C:1}" redirectType="Found" />
 </rule>
</rewrite>

要求的 URL /default.aspx?tabid=2&subtabid=29 將會重新導向至 http://www.contoso.com/diagnostics
要求的 URL /default.aspx?tabid=2&subtabid=24 將會重新導向至 http://www.contoso.com/webcasts
要求的網址 /default.aspx?tabid=7116 將會重新導向至 http://www.contoso.com/php
要求的 URL /default.aspx 將不會重新導向,因為重寫對應不包含 key=“/default.aspx”的專案;因此重寫對應會傳回不符合條件模式的空字串,因此不會執行規則動作。