URL 書き換えモジュール構成リファレンス

2023-07-19

この記事では、URL 書き換えモジュールの概要と、モジュールで使用される構成の概念について説明します。

機能の概要

URL 書き換えモジュールは、要求 URL を、ユーザーまたは Web アプリケーションに表示されるシンプルでわかりやすい検索エンジンフレンドリアドレスに書き換えます。 URL 書き換えでは、定義された規則を使用して、IIS Web サーバーによって処理される前に、要求 URL を評価し、ルールで定義されたアドレスにマップします。正規表現とワイルドカードを含む URL 書き換えロジックを定義できます。ルールは、要求 URL、HTTP ヘッダー、およびサーバー変数に基づいて適用できます。モジュールの主な目的は、要求 URL をよりわかりやすい URL に書き換することですが、モジュールを使用して、リダイレクトを実行するルールの定義、カスタム応答の送信、要求の中止を行うこともできます。

書き換えルールの概要

書き換えルールでは、要求 URL を比較または照合するロジックと、比較が成功した場合の対処方法を定義します。

書き換えルールは、次の部分で構成されます。

パターン – ルールパターンは、URL 文字列の照合に使用される正規表現またはワイルドカードパターンを指定するために使用されます。
Conditions – オプションの条件コレクションは、URL 文字列がルールパターンと一致する場合に実行する追加の論理操作を指定するために使用されます。条件内で、HTTP ヘッダーまたはサーバー変数の特定の値を確認したり、要求された URL が物理ファイルシステム上のファイルまたはディレクトリに対応しているかどうかを確認したりできます。
アクション – アクションは、URL 文字列がルールパターンと一致し、すべてのルール条件が満たされた場合の対処方法を指定するために使用されます。

書き換えルールのスコープ

書き換えルールは、次の 2 つの異なるコレクションで定義できます。

<globalRules> – このコレクションのルールは、サーバーレベルでのみ定義できます。グローバルルールは、サーバー全体の URL 書き換えロジックを定義するために使用されます。これらの規則は ApplicationHost.config ファイル内で定義されており、下位の構成レベルではオーバーライドまたは無効にできません。グローバルルールは、常に絶対 URL のパス (つまり、サーバー名のない要求された URI) で動作します。これらの規則は、IIS 要求処理パイプライン (PreBeginRequest イベント) の早い段階で評価されます。
<rules> – このコレクション内のルールは分散ルールと呼ばれ、構成階層内の任意のレベルで定義できます。分散ルールは、特定の構成スコープに固有の URL 書き換えロジックを定義するために使用されます。この種類の規則は、Web.config ファイルを使用するか、ApplicationHost.config または Web.config ファイル内の <___location> タグを使用して、任意の構成レベルで追加できます。分散ルールは、定義されている Web.config ファイルの場所を基準とした URL パスに対して動作します。分散ルールが <___location> タグ内で定義されている場合、その <___location> タグに指定されたパスを基準にした URL パスに対して動作します。これらのルールは、IIS パイプラインの BeginRequest イベントで評価されます。

ルールの評価

IIS の各構成レベルには、0 個以上の書き換え規則を定義できます。ルールは、指定された順序で評価されます。 URL 書き換えモジュールは、次のアルゴリズムを使用してルールのセットを処理します。

まず、URL がルールのパターンと照合されます。一致しない場合、URL 書き換えモジュールはそのルールの処理を直ちに停止し、次のルールに進みます。
パターンが一致し、ルールの条件がない場合、URL 書き換えモジュールはこのルールに対して指定されたアクションを実行し、次のルールに進み、置換された URL をそのルールの入力として使用します。
パターンが一致し、ルールの条件がある場合は、URL 書き換えモジュールによって条件が評価されます。評価が成功すると、指定されたルールアクションが実行され、書き換えられた URL が後続のルールへの入力として使用されます。

ルールで StopProcessing フラグが 有効になっている場合があります。ルールアクションが実行され (ルールが一致した場合)、このフラグがオンになると、後続のルールが処理されなくなり、要求が IIS 要求パイプラインに渡されることを意味します。既定では、このフラグはオフになっています。

ルールの継承

ルールが複数の構成レベルで定義されている場合、URL 書き換えモジュールはルールを次の順序で評価します。

すべてのグローバルルールを評価します。
親構成レベルの分散ルールと、現在の構成レベルの規則を含むルールセットを評価します。評価は親子の順序で実行されます。つまり、親ルールは最初に評価され、最後の子レベルで定義された規則は最後に評価されます。

元の URL の保持

URL 書き換えモジュールは、要求された元の URL パスを次のサーバー変数に保持します。

HTTP_X_ORIGINAL_URL – このサーバー変数には、デコードされた形式の元の URL が含まれています。
UNENCODED_URL – このサーバー変数には、元の URL が Web クライアントから要求されたとおりに格納され、元のエンコードはすべて保持されます。

書き換えルールから URL パーツにアクセスする

書き換えルールから URL 文字列の特定の部分にアクセスする方法を理解することが重要です。

以下の形式の HTTP URL: http(s)://<host>:<port>/<path>?<querystring>

<path>はルールのパターンと照合されます。
<querystring>はQUERY_STRINGと呼ばれるサーバー変数で使用でき、ルール内の条件を使用してアクセスできます。
<host>はサーバー変数HTTP_HOSTで使用でき、ルール内の条件を使用してアクセスできます。
<port>はサーバー変数SERVER_PORTで使用でき、ルール内の条件を使用してアクセスできます。
サーバー変数SERVER_PORT_SECUREと HTTPS を使用して、セキュリティで保護された接続が使用されたかどうかを判断できます。これらのサーバー変数には、ルール内の条件を使用してアクセスできます。
サーバー変数REQUEST_URIを使用して、クエリ文字列を含む、要求された URL パス全体にアクセスできます。

たとえば、この URL に対して要求が行われた場合: http://www.mysite.com/content/default.aspx?tabid=2&subtabid=3、サイトレベルで書き換えルールが定義されている場合は、次のようになります。

ルールパターンは、入力として content/default.aspx URL 文字列を取得します。
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 サーバー変数を使用できます。詳細については、「書き換えルールでのサーバー変数の使用」を参照してください。

パターンは、書き換えルールの <match> 要素内で指定されます。

ルールパターンの構文

ルールパターン構文は、ルールの patternSyntax 属性を使用して指定できます。この属性は、次のいずれかのオプションに設定できます。

ECMAScript – Perl 互換 (ECMAScript 標準準拠) 正規表現構文。これは、任意のルールの既定のオプションです。これはパターン形式の例です: "^([_0-9a-zA-Z-]+/)?(wp-.*)"

ワイルドカード – IIS HTTP リダイレクトモジュールで使用される。 "/Scripts/*_in.???" という形式のパターンの例を次に示します。アスタリスク ("*") は"任意の数の文字に一致し、バックリファレンスでキャプチャ" を意味し、"?" は 1 文字に一致することを意味します (バックリファレンスは作成されません)。

patternSyntax 属性のスコープはルールごとであり、現在のルールのパターンとそのルールの条件内で使用されるすべてのパターンに適用されます。

ルールパターンのプロパティ

パターンは、<match> 要素の negate 属性を使用して否定できます。この属性を使用すると、現在の URL が指定されたパターンと一致 しない 場合にのみ、ルールアクションが実行されます。

既定では、大文字と小文字を区別しないパターンマッチングが使用されます。大文字と小文字の区別を有効にするには、ルールの <match> 要素の ignoreCase 属性を使用できます。

ルールの条件

ルール条件を使用すると、現在の URL 文字列以外の入力に基づいて、ルール評価用の追加ロジックを定義できます。任意のルールに 0 個以上の条件を設定できます。ルールの条件は、ルールパターンの一致が成功した後に評価されます。

条件は、書き換えルールの <conditions> コレクション内で定義されます。このコレクションには、条件の評価方法を制御する logicalGrouping という属性があります。ルールに条件がある場合、ルールアクションはルールパターンが一致し、次の場合にのみ実行されます。

logicalGrouping="MatchAll" が使用されている場合、すべての条件が true として評価されました。
logicalGrouping="MatchAny" が使用されている場合、条件の少なくとも 1 つが true と評価されました。

条件は、次のプロパティを指定することによって定義されます。

入力文字列
照合する種類

条件入力では、条件評価の入力として使用する項目を指定します。条件入力は、サーバー変数と、以前の条件パターンやルールパターンへのバック参照を含めることができる任意の文字列です。

一致タイプは、次の3つのオプションのいずれかです。

IsFile – この一致の種類は、入力文字列にファイルシステム上のファイルへの物理パスが含まれているかどうかを判断するために使用されます。条件入力文字列が指定されていない場合、URL 書き換えモジュールは、要求されたファイルの物理パスを条件入力の既定値として使用します。この一致の種類は、分散ルールにのみ使用できます。
IsDirectory – この一致の種類は、入力文字列にファイルシステム上のディレクトリへの物理パスが含まれているかどうかを判断するために使用されます。条件入力文字列が指定されていない場合、URL 書き換えモジュールは、要求されたファイルの物理パスを条件入力の既定値として使用します。この一致の種類は、分散ルールにのみ使用できます。
パターン – この一致型は、任意の入力文字列が正規表現パターンと照合される条件を表すために使用されます。条件パターンは、正規表現構文を使用するか、ワイルドカード構文を使用して指定できます。条件で使用するパターンの種類は、この条件が属するルールに対して定義されている patternSyntax フラグの値によって異なります。この条件の種類には、パターンマッチングを制御する 2 つの関連属性があります。
- pattern – この属性を使用して、実際のパターンを指定します。
- ignoreCase – この属性を使用して、条件のパターンマッチングで大文字と小文字を区別するか、区別しないかを制御します。

さらに、条件評価の結果は 、否定 属性を使用して否定できます。これは、次の例のように、要求された URL がファイルではないかどうかをチェックする条件を指定するために使用できます。

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

ルールアクション

書き換えルールアクションは、現在の URL がルールパターンと一致し、条件の評価が成功したときに実行されます (ルールの構成によっては、一致したすべての条件または一致した条件のいずれか 1 つ以上のいずれか)。使用できるアクションにはいくつかの種類があり、<action>構成要素の type 属性を使用して、ルールが実行するアクションを指定できます。以降のセクションでは、さまざまなアクションの種類と、特定のアクションの種類に関連する構成オプションについて説明します。

書き換え操作

書き換えアクションは、現在の URL 文字列を置換文字列に置き換えます。置換文字列では、常に URL パスを指定する必要があります (例: contoso/test/default.aspx)。ファイルシステム上の物理パスを含む置換 ( C:\inetpub\wwwrootなど) は IIS ではサポートされないことに注意してください。

書き換えアクションには、次の構成オプションがあります。

url – 現在の URL を書き換えるときに使用する置換文字列です。置換 URL は、次を含めることができる文字列値です。
- 条件とルールパターンへのバックリファレンス。 (詳細については、バックリファレンスの使用方法に関するセクションを参照してください)。
- サーバー変数。 (詳細については、サーバー変数の使用方法に関するセクションを参照してください。
appendQueryString – 置換中に現在の URL のクエリ文字列を保持するかどうかを指定します。既定では、 appendQueryString フラグの値が指定されていない場合、TRUE と見なされます。つまり、元の URL のクエリ文字列が置換された URL に追加されます。

リダイレクトアクション

リダイレクト アクションは、リダイレクト応答をクライアントに返すように URL 書き換えモジュールに指示します。リダイレクト状態コード (3xx) は、このアクションのパラメーターとして指定できます。応答の Location フィールドには、ルールで指定された置換文字列が含まれています。

リダイレクトルールの置換 URL は、次のいずれかの形式で指定できます。

相対 URL パス – contoso/test/default.aspx
絶対 URI – https://example.com/contoso/test/default.aspx

リダイレクトアクションの使用は、 リダイレクト の実行後に現在の URL に対して後続のルールが評価されていないことを意味します。

リダイレクト アクションには、次の構成オプションがあります。

url – リダイレクト URL として置換文字列を使用します。置換 URL は、次を含めることができる文字列です。
- 条件とルールパターンへのバックリファレンス。 (詳細については、バックリファレンスの使用方法に関するセクションを参照してください)。
- サーバー変数。 (詳細については、サーバー変数の使用方法に関するセクションを参照してください。
appendQueryString – 置換中に現在の URL のクエリ文字列を保持するかどうかを指定します。 AppendQueryString フラグが指定されていない場合、既定では TRUE と見なされます。つまり、元の URL のクエリ文字列が置換された URL に追加されます。
redirectType – リダイレクト時に使用する状態コードを指定します。
- 301 – 永続的
- 302 – 見つかりました
- 303 – その他を参照
- 307 – 一時的
注

HTTP 状態コード 308 (永続的リダイレクト) は、URL 書き換えモジュールではサポートされていません。

CustomResponse アクション

CustomResponse アクションを実行すると、ユーザー指定の状態コード、サブコード、および理由を使用して、URL 書き換えモジュールが HTTP クライアントに応答します。 CustomResponse アクションを使用すると、このアクションの実行後に、現在の URL に対して後続のルールが評価されません。

CustomResponse アクションには、次の構成オプションがあります。

statusCode – クライアントへの応答で使用する状態コードを指定します。
subStatusCode – クライアントへの応答で使用するサブステータスコードを指定します。
statusReason – 状態 コードで使用する理由フレーズを指定します。
statusDescription – 応答の本文に配置する 1 行の説明を指定します。

AbortRequest アクション

AbortRequest アクションにより、URL 書き換えモジュールは現在の要求の HTTP 接続を削除します。アクションにはパラメーターがありません。このアクションを使用すると、このアクションの実行後に現在の URL に対して後続のルールが評価されません。

なしのアクション

None アクションは、アクションが実行されていないことを指定するために使用されます。

書き換えルールでのサーバー変数の使用

サーバー変数は、現在の HTTP 要求に関する追加情報を提供します。この情報を使用して、書き換えの決定を行うか、書き換えられた URL を作成できます。サーバー変数は、書き換えルール内の次の場所で参照できます。

条件入力文字列の中に
ルール置換文字列では、具体的には次のようになります。
- 書き換えとリダイレクトアクションの url 属性
- CustomResponse アクションの statusLine と responseLine

サーバー変数は、{VARIABLE_NAME} 構文を使用して参照できます。たとえば、次の条件では、QUERY_STRING サーバー変数を使用します。

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

サーバー変数を使用して、現在の要求から HTTP ヘッダーにアクセスすることもできます。現在の要求によって提供されるすべての HTTP ヘッダーは、この名前付け規則に従って生成された名前を持つサーバー変数として表されます。

HTTP ヘッダー名内のすべてのダッシュ ("-") シンボルは、アンダースコア記号 ("_") に変換されます。
HTTP ヘッダー名のすべての文字は大文字に変換されます。
"HTTP_" プレフィックスがヘッダー名に追加されます。

たとえば、書き換えルールから HTTP ヘッダー "user-agent" にアクセスするには、{HTTP_USER_AGENT} サーバー変数を使用できます。

書き換えルールでのバックリファレンスの使用

ルールまたは条件の入力の一部は、バックリファレンスでキャプチャできます。これらを使用して、ルールアクション内に置換 URL を作成したり、ルール条件の入力文字列を作成したりできます。

バック参照は、ルールに使用されるパターン構文の種類に応じて、さまざまな方法で生成されます。 ECMAScript パターン構文を使用する場合は、バックリファレンスをキャプチャする必要があるパターンの部分をかっこで囲むことで、バックリファレンスを作成できます。たとえば、パターン ([0-9]+)/([a-z]+).html では、この要求された URL から 07 と アーティ クルがバックリファレンスでキャプチャされます: 07/article.html。 "ワイルドカード" パターン構文を使用する場合、パターンでアスタリスク記号 (*) を使用すると、バック参照が常に作成されます。パターンで "?" が使用されている場合、バック参照は作成されません。たとえば、パターン */*.html は contoso をキャプチャし、要求された URL contoso/test.htmlからバックリファレンスでテストします。

バック参照の使用は、キャプチャに使用されたパターン構文に関係なく同じです。バック参照は、書き換えルール内の次の場所で使用できます。

条件の入力文字列
ルールアクションでは、具体的には次のようになります。
- 書き換えとリダイレクトアクションの url 属性
- CustomResponse アクションの statusLine と responseLine
書き換えマップのキーパラメーター内

条件パターンへのバックリファレンスは {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 書き換えモジュールは、次の目的で IIS 出力キャッシュの動作を制御します。

書き換えられた URL の応答のカーネルモードとユーザーモード出力キャッシュを最適に利用するため、URL 書き換えモジュールを使用する Web アプリケーションのパフォーマンスが向上します。
URL の書き換えによってキャッシュロジックに違反する可能性がある場合は、応答のキャッシュを防止します。

モジュールは、特定のキャッシュプロパティを変更するか、キャッシュを完全に無効にすることで、出力キャッシュを制御します。 IIS 構成または IIS パイプライン内の他のモジュールによって無効にされている場合、モジュールは出力キャッシュを有効にできません。出力キャッシュは次のように制御されます。

モジュールは常に、ユーザーモードキャッシュ設定 varyByHeader="HTTP_X_ORIGINAL_URL" を設定します。これにより、ユーザーモードのキャッシュが有効になっている場合、モジュールはキャッシュエントリのキーを構築するために元の URL を考慮に入れるようにします。
書き換え規則セットで、プロセスの有効期間を通じて一定の値または要求された URL から派生した値を持つサーバー変数を使用する場合、規則セットは出力キャッシュに対して安全と見なされます。つまり、URL 書き換えモジュールは、手順 1 で説明したように varyByHeader を設定する以外の方法で既存のキャッシュポリシーを変更しません。

次のサーバー変数は、書き換え規則で使用される場合、出力キャッシュポリシーには影響しません。
- "CACHE_URL"
- DOCUMENT_ROOT（ルートディレクトリ）
- HTTP_URL
- "HTTP_HOST"
- "PATH_INFO"
- 翻訳されたパス
- "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"
- サーバーソフトウェア
- "SSI_EXEC_DISABLED"
書き換え規則セットで、上記の一覧に記載されていないサーバー変数が使用されている場合、規則セットは出力キャッシュでは安全でないと見なされます。つまり、URL 書き換えモジュールでは、要求 URL が書き換えられたかどうかにかかわらず、すべての要求のカーネルモードキャッシュが無効になります。さらに、モジュールは、ルールセットで使用されるすべてのサーバー変数値の連結文字列を含むキャッシュプロパティ varyByValue を設定することで、ユーザーモードキャッシュのキャッシュポリシーを変更します。

文字列関数

書き換えルールアクション内の値を変更するために使用できる 3 つの文字列関数と、任意の条件があります。

ToLower - 小文字に変換された入力文字列を返します。
UrlEncode - URL エンコード形式に変換された入力文字列を返します。この関数は、書き換えルールの置換 URL に特殊文字が含まれている場合に使用できます (たとえば、ASCII 以外の文字や URI の安全でない文字)。
UrlDecode - URL エンコードされた入力文字列をデコードします。この関数は、パターンと照合する前に条件入力をデコードするために使用できます。

関数は、次の構文を使用して呼び出すことができます。

{function_name:any_string}

ここで、"function_name" は次のようになります。"ToLower"、"UrlEncode"、"UrlDecode"。 "Any_string" には、リテラル文字列またはサーバー変数またはバック参照を使用して構築された文字列を指定できます。たとえば、文字列関数の有効な呼び出しを次に示します。

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

文字列関数は、書き換えルール内の次の場所で使用できます。

条件入力文字列
ルール置換文字列では、具体的には次のようになります。
- 書き換えアクションとリダイレクト アクションの url 属性
- CustomResponse アクションの statusLine 属性と responseLine 属性

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 を検索するために、書き換えマップを参照する書き換えルールが 1 つ作成されます。

書き換えマップは、次の例のように、名前と値のペア文字列の名前付きコレクションを定義します。

<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>

書き換えマップは名前によって一意に識別され、0 個以上のキー値エントリを含めることができます。さらに、書き換えマップでは、キーが見つからないときに使用する既定値を指定できます。これは defaultValue 属性を使用して制御されます。既定では、空の文字列が既定値として使用されます。

ファイルレベルを除き、任意の数の書き換えマップを任意の構成レベルで使用できます。書き換えマップは、 <rewriteMaps> コレクション要素内にあります。

書き換えマップは、次の構文を使用して書き換えルール内で参照されます。

{RewriteMapName:Key}

Key パラメーターには任意の文字列を指定でき、ルールまたは条件パターンへのバック参照を含めることができます。たとえば、書き換えマップの有効な使用方法を次に示します。

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

書き換えマップへの参照は、書き換えマップ参照内でパラメーターとして渡されたキーを使用して検索された値に置き換えます。キーが見つからなかった場合は、その書き換えマップの既定値が使用されます。

書き換えマップは、書き換えルール内の次の場所で参照できます。

条件入力文字列
ルール置換文字列では、具体的には次のようになります。
- 書き換えアクションとリダイレクト アクションの url 属性
- CustomResponse アクションの statusLine と responseLine

例 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 に書き換えられます。
書き換えマップに key="/default.aspx " の要素が含まれていないため、要求された URL /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>