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

作成者 : Ruslan Yakushev
発行日 : 2008 年 5 月 28 日 (作業者 : ruslany(英語))
更新日 : 2009 年 2 月 20 日 (作業者 : ruslany(英語))

目次

• 機能の概要
• 書き換えルールの概要
  • 書き換えルールの範囲
  • 規則の評価
  • ルールの継承
  • 元の URL の保持
• 書き換えルールから URL 部分へのアクセス
• 書き換えルールの構成
  • ルール パターン
    • ルール パターンの構文
    • ルール パターンのプロパティ
  • ルールの条件
  • ルール アクション
    • Rewrite アクション
    • Redirect アクション
    • CustomResponse アクション
    • AbortRequest アクション
    • None アクション
• 書き換えルールでのサーバー変数の使用
• 書き換えルールでの逆参照の使用
• IIS 出力キャッシュとのやりとり
• 文字列関数
• 書き換えマップ

機能の概要

URL 書き換えモジュールは、Web サーバーが URL を処理する前に、ルールに基づいて要求 URL を変更する書き換えメカニズムを提供します。このモジュールを使用して、正規表現やワイルドカードを使用する URL 書き換えロジックを表現したり、HTTP ヘッダーおよびサーバー変数に基づいて書き換えを判断したりできます。このモジュールの主な用途は要求された URL を書き換えることですが、書き換えルール内で表現されるロジックに基づいて、リダイレクトの実行、カスタム応答の送信、または要求の中止を行うこともできます。

検索エンジンで使いやすい形式の URL を内部用の形式に書き換える、リダイレクトを実行する、Web サイト上の特定コンテンツへのアクセスをブロックするなど、URL 書き換えモジュールはさまざまなタスクに使用できます。

書き換えルールの概要

URL 書き換えモジュールで使用される主な構成の概念は、書き換えルールの概念です。書き換えルールを使用して、要求された URL を何と比較またはマッチするか、および比較が成功した場合にどうするか、に関するロジックを表します。

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

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

書き換えルールの範囲

書き換えルールは、2 種類のコレクションで定義できます。

• <globalRules> - このコレクションのルールは、サーバー レベルでのみ定義できます。グローバル ルールを使用して、サーバー全体に及ぶ書き換えロジックを定義します。これらのルールは 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 書き換えモジュールは、次のアルゴリズムを使用して一連のルールを処理します。

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

ルールで StopProcessing フラグがオンになっている場合があります。このフラグがオンの場合、以降のルールは処理されず、このルールで生成された URL が IIS 要求パイプラインに渡される (ルールが一致した場合) ことを示します。既定では、このフラグはオフになっています。

ルールの継承

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

1. すべてのグローバル ルールを評価します。
2. 親構成レベルからの分散ルールおよび現在の構成レベルのルールを含むルール セットを評価します。評価は親から子の順に実行されます。つまり、親ルールが最初に評価され、最後の子レベルで定義されたルールが最後に評価されます。

元の URL の保持

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

• HTTP_X_ORIGINAL_URL - このサーバー変数には、元の URL がデコードされた形式で保持されます。
• UNENCODED_URL - このサーバー変数には、元の URL が、Web クライアントによって要求されたとおりに保持されます。元のエンコードがすべて保持されます。

書き換えルールから URL 部分へのアクセス

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

http(s)://<host>:<port>/<path>?<querystring> という形式の HTTP URL の場合、次のようになります。

• <path> はルールのパターンに対して照合されます。

• <querystring> は QUERY_STRING と呼ばれるサーバー変数で使用可能であり、ルール内の条件を使用してアクセスできます。

• <host> はサーバー変数 HTTP_HOST で使用可能であり、ルール内の条件を使用してアクセスできます。

• <port> はサーバー変数 SERVER_PORT で使用可能であり、ルール内の条件を使用してアクセスできます。

• サーバー変数 SERVER_PORT_SECURE および HTTPS を使用して、セキュリティ保護された接続が使用されたかどうか判断します。これらのサーバー変数は、ルール内の条件を使用してアクセスできます。

• サーバー変数 REQUEST_URI は、クエリ文字列を含む、要求された URL パス全体にアクセスするために使用します。

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

• ルール パターンは、入力として 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 サーバー変数 は /default.aspx?tabid=2&subtabid=3 を含みます。

分散ルールに渡される入力 URL 文字列は、そのルールが定義された Web.config ファイルの場所に対して相対的であることに注意してください。たとえば、http://www.mysite.com/content/default.aspx?tabid=2&subtabid=3 という URL が要求され、書き換えルールが /content ディレクトリで定義されている場合、ルールは入力として URL 文字列 default.aspx を取得します。

書き換えルールの構成

ルール パターン

書き換えルール パターンを使用して、現在の URL パスの一致対象を指定します。"現在の" とは、ルールが適用される時点での URL パスの値を意味します。現在のルールより前にルールがあった場合、それらのルールで当初要求された URL が照合されて、元の URL が変更されている場合があります。パターンに対して評価される URL 文字列は、クエリ文字列を含みません。ルール評価にクエリ文字列を含めるには、ルールの条件で QUERY_STRING サーバー変数を使用します。詳しくは、「書き換えルールでのサーバー変数の使用」を参照してください。

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

ルール パターン構文

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

ECMAScript - Perl 互換の (ECMAScript (英語) 標準に準拠した) 正規表現構文です。これは、ルールの既定のオプションです。この形式のパターンは "^([_0-9a-zA-Z-]+/)?(wp-.*)" のようになります。

Wildcard - IIS 7.0 HTTP リダイレクト モジュールで使用されるワイルドカード(英語)構文です。この形式のパターンは、たとえば "/Scripts/*_in.???" のようになります。ここで、アスタリスク ("*") は "任意の数の任意の文字と一致し、それらを逆参照でキャプチャする" ことを意味し、"?" は 1 文字と一致することを意味します (逆参照は作成されません)。

patternSyntax 属性の範囲はルールごとです。つまり、現在のルールのパターン、およびそのルールの条件内で使用されるすべてのパターンに適用されます。

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

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

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

ルールの条件

ルールの条件を使用して、現在の URL 文字列以外の入力に基づく、ルール評価の追加ロジックを定義できます。ルールには、ゼロ個またはそれ以上の条件を指定できます。ルールの条件は、ルール パターン マッチが成功した後に評価されます。

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

• logicalGrouping="MatchAll" が使用された場合、すべての条件が評価されます。

• logicalGrouping="MatchAny" が使用された場合、少なくとも 1 つの条件が評価されます。

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

• 入力文字列

• 一致の種類

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

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

• IsFile - この一致の種類は、入力文字列に、ファイル システム上のファイルの物理パスが含まれるかどうか確認するために使用されます。条件入力文字列が指定されていない場合、URL 書き換えモジュールは、条件入力の規定値として、要求されたファイルの物理パスを使用します。この一致の種類は、分散ルールの場合のみ使用できます。

• IsDirectory - この一致の種類は、入力文字列に、ファイル システム上のディレクトリの物理パスが含まれるかどうか確認するために使用されます。条件入力文字列が指定されていない場合、URL 書き換えモジュールは、条件入力の規定値として、要求されたファイルの物理パスを使用します。この一致の種類は、分散ルールの場合のみ使用できます。

• Pattern - この一致の種類を使用して、任意の入力文字列を正規表現パターンに対して一致させる条件を表します。条件パターンは、正規表現構文またはワイルドカード構文を使用して指定できます。条件で使用するパターンの種類は、この条件が属するルールに対して定義された patternSyntax フラグの値に依存します。この条件の種類には、パターン マッチを制御する 2 つの関連属性があります。

  • pattern - この属性を使用して、実際のパターンを指定します。

  • ignoreCase - この属性を使用して、条件のパターン マッチで大文字と小文字を区別するかどうか指定します。

また、negate 属性を使用して、条件評価の結果を否定できます。これは、要求された URL がファイルではないかどうかを確認する条件を指定する場合に使用できます。

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

ルール アクション

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

Rewrite アクション

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

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

• url - 現在の URL を書き換えるときに使用する置換文字列です。置換 URL は自由な形式の文字列で、次の情報を含めることができます。

  • 条件およびルール パターンへの逆参照。(詳細は、逆参照の使用方法に関するセクションを参照してください。)

  • サーバー変数。(詳細は、サーバー変数の使用方法に関するセクションを参照してください。)

• appendQueryString - 置換時に、現在の URL のクエリ文字列を保持するかどうかを指定します。appendQueryString フラグの値が指定されていない場合、既定では TRUE と見なされます。つまり、元の URL のクエリ文字列が置換された URL に追加されます。

Redirect アクション

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

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

• 相対 URL パス - contoso/test/default.aspx

• 絶対 URL - https://example.com/contoso/test/default.aspx

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

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

• url - リダイレクト URL として置換文字列を使用します。置換 URL は自由な形式の文字列で、次の情報を含めることができます。

  • 条件およびルール パターンへの逆参照。(詳細は、逆参照の使用方法に関するセクションを参照してください。)

  • サーバー変数。(詳細は、サーバー変数の使用方法に関するセクションを参照してください。)

• appendQueryString - 置換時に、現在の URL のクエリ文字列を保持するかどうかを指定します。appendQueryString フラグが指定されていない場合、既定では TRUE と見なされます。つまり、元の URL のクエリ文字列が置換された URL に追加されます。

• redirectType - リダイレクト時に使用する状態コードを指定します。

  • 301 - 永続的

  • 302 - 検出

  • 303 - その他

  • 307 - 一時的

CustomResponse アクション

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

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

• statusCode - クライアントへの応答に使用する状態コードを指定します。

• subStatusCode - クライアントへの応答に使用するサブ状態コードを指定します。

• statusReason - 状態コードと共に使用する理由フレーズを指定します。

• statusDescription - 応答の本文に配置する 1 行の記述を指定します。

AbortRequest アクション

AbortRequest アクションを指定すると、URL 書き換えモジュールは、現在の要求の HTTP 接続をドロップします。このアクションには、パラメーターはありません。このアクションを使用すると、このアクションが実行された後は、現在の URL に対して以降のルールが評価されないことになります。

None アクション

どのアクションも実行しない場合は None アクションを使用します。

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

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

• 条件入力文字列

• ルール置換文字列内の次の場所。

  • Rewrite アクションおよび Redirect アクションの url 属性

  • CustomResponse アクションの statusLine および responseLine

サーバー変数は、{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 パターン構文を使用する場合、パターンのうち、逆参照をキャプチャする必要がある部分にかっこを付けることによって、逆参照を作成できます。たとえば、07/article.html という要求 URL から逆参照を行う場合、パターン ([0-9]+)/([a-z]+)\.html は、07 および article をキャプチャします。"ワイルドカード" パターン構文を使用する場合、パターンにアスタリスク (*) が使用されると、常に逆参照が作成されます。パターンで "?" が使用された場合、逆参照は作成されません。たとえば、contoso/test.html という要求 URL から逆参照を行う場合、パターン */*.html は、contoso および test をキャプチャします。

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

• 条件入力文字列

• ルール アクション内の次の場所。

  • Rewrite アクションおよび Redirect アクションの url 属性

  • CustomResponse アクションの statusLine および responseLine

• 書き換えマップに対する key パラメーター

条件パターンへの逆参照は {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 出力キャッシュの動作を制御します。

1. 書き換えられた URL の応答について、カーネル モードおよびユーザー モードの出力キャッシュを最適に利用し、URL 書き換えモジュールを使用する Web アプリケーションのパフォーマンスを改善する。
2. URL 書き換えによりキャッシュ ロジック違反となる場合に、応答をキャッシュしないようにする。

特定のキャッシュ プロパティを変更するか、キャッシュ自体を無効にすることによって、モジュールは出力キャッシュを制御します。IIS 構成または IIS パイプライン内の別のモジュールによって出力キャッシュが無効になっている場合、URL 書き換えモジュールで出力キャッシュを有効にすることはできません。出力キャッシュは、次のロジックに従って制御されます。

1. モジュールは、ユーザー モード キャッシュ設定を常に varyByHeader="HTTP_X_ORIGINAL_URL" に設定します。これによって、ユーザー モード キャッシュが有効になっていれば、元の URL を考慮してキャッシュ エントリのキーが構築されます。

2. 書き換えルール設定にサーバー変数を使用する場合、その値がプロセスのライフサイクルを通じて一定であるか、または要求された URL から派生していれば、出力キャッシュについてこのルール セットが安全であると見なされます。これは、上記の varyByHeader の設定を除き、URL 書き換えモジュールは既存のキャッシュ ポリシーを変更しないことを意味します。

次のサーバー変数を書き換えルールで使用した場合、出力キャッシュ ポリシーには一切影響がありません。

"CACHE_URL"、
"DOCUMENT_ROOT"、
"HTTP_URL"、
"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 が、ルール セットで使用されたすべてのサーバー変数の値の連結文字列を含むように設定します。

文字列関数

書き換えルール アクションおよび任意の条件入力の値を変更するために使用可能な文字列関数は、次の 3 つです。

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

この関数は、次の構文を使用して呼び出されます。

{function_name:any_string}

ここで、"function_name" は "ToLower"、"UriEncode"、"UriDecode" のいずれかです。"any_string" は、リテラル文字列、あるいはサーバー変数または逆参照を使用して構築された文字列のいずれかです。次のコードは、文字列関数の有効な呼び出し例です。

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

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

• 条件入力文字列

• ルール置換文字列内の次の場所。

  • Rewrite アクションおよび Redirect アクションの url 属性

  • CustomResponse アクションの statusLine および responseLine

ToLower 関数を使用したルールの例

<rule name="Redirect to canonical url">
 <match url=”^(.+)” > <!-- rule back-reference is captured here -->
 <conditions>
  <!-- Check if the requested domain is not 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>

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

ファイル レベル以外の任意の構成レベルで、任意の数の書き換えマップを指定できます。書き換えマップは、コレクション要素 <rewriteMaps> 内に配置されます。

書き換えルールにおいて、次の構文を使用して書き換えマップを参照します。

{RewriteMapName:Key}

ここで、"Key" パラメーターは任意の文字列で、ルールまたは条件パターンへの逆参照を含むことができます。次のコードは、書き換えマップの有効な使用例です。

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

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

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

• 条件入力文字列

• ルール置換文字列内の次の場所。

  • Rewrite アクションおよび Redirect アクションの 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 に書き換えられます。要求された URL が default.aspx の場合、URL は書き換えられません。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 にリダイレクトされます。要求された URL /default.aspx?tabid=7116 は、http://www.contoso.com/php
にリダイレクトされます。要求された URL が default.aspx の場合、リダイレクトされません。key="default.aspx" という要素が書き換えマップに含まれないので書き換えマップは空の文字列を返しますが、これは条件パターンに一致しないため、ルール アクションが実行されないからです。