次の方法で共有

URL Rewrite Module 2.0 の使用

  • [アーティクル]

著者 Ruslan Yakushev

はじめに

ドキュメントのこのセクションは、URL Rewrite 2.0 for IIS 7 に適用されます。

URL Rewrite Module 2.0 for IIS 7 以降は、バージョン 1.1 のすべての機能を含む増分リリースであり、.NET の拡張性と送信応答の書き換えのサポートを追加します。 具体的には、次の用途に使用できます:

  • .NET で記述された書き換えプロバイダーを使用して複雑な書き換えロジックを実装します
  • 応答 HTML 内の Web アプリケーションによって生成された URL を、よりユーザー フレンドリで検索エンジンに対応した URL に置き換えます
  • リバース プロキシの背後にある Web アプリケーションによって生成された HTML マークアップ内のリンクを変更します。
  • 正規表現パターン マッチングを使用して、HTTP 応答の内容を修正します。
  • HTTP 要求ヘッダーと応答ヘッダーと IIS サーバー変数を変更します。

機能

URL Rewrite 2.0 には、次の主な機能が含まれています:

  • カスタム書き換えプロバイダー (RTW の新機能)。 書き換えプロバイダーは、URL 書き換えロジックを正規表現パターンで表現できない場合、または web.config ファイル の外部 (e.g. SQL データベースまたはテキスト ファイル) に格納されているデータに基づいて書き換えの決定を行う必要がある場合に使用できます。 顧客の書き換えプロバイダーは、任意の .NET 言語で実装できます。
  • ルールベースの応答書き換えエンジン。 アウトバウンド規則は、応答の一部を比較する内容と、比較が成功した場合の対処方法のロジックを表すために使用されます。 Web サーバーとサイト管理者は、アウトバウンド規則を使用して、複雑な応答書き換えロジックを定義できます。
  • 特定の HTML タグのコンテンツ内での書き換え。 特定の一致の応答全体をスキャンする代わりに、ルールを特定の HTML タグ (<a>、<img> など) の内部のみを検索するように構成できます。このようにパターンが大幅に簡略化され、ルールをコンテンツに適用するプロセスは、応答全体にパターンを適用する場合と比べてはるかに高速になります。
  • 送信規則の事前条件。 すべての応答に書き換えルールを適用することは高価な操作であり、ほとんどの場合は必要ありません。 事前条件を使用して応答メタデータを確認し、アウトバウンド規則の評価を適用する必要があるかどうかを判断します。
  • サーバー変数と HTTP 要求ヘッダーの書き換え。 書き換えルールを使用して、さまざまな IIS サーバー変数と HTTP 要求ヘッダーを設定できます。
  • HTTP 応答ヘッダーの書き換え。 送信書き換えルールは、既存の HTTP 応答ヘッダーを変更したり、新しい HTTP 応答ヘッダーを設定したりするために使用できます。
  • サーバー変数の許可リスト。 分散書き換えルールが、Web アプリケーションのセキュリティまたは実行時の動作に影響する可能性がある IIS サーバー変数を誤ってまたは意図的に変更しないようにするには、変更可能なサーバー変数を許可リストに明示的に追加する必要があります。
  • HtmlEncode 関数。 送信書き換えでは、多くの場合、信頼されていないデータ (クエリ文字列や HTTP ヘッダーなど) を使用して、HTTP 応答に挿入する置換文字列を作成する場合があります。 このような場合、HtmlEncode 関数を使用して、クライアント側スクリプトが応答に挿入されないようにする必要があります。これにより、クロスサイト スクリプティングの脆弱性が発生する可能性があります。
  • ルールの条件全体にわたるキャプチャ グループの追跡。 URL 書き換え 1.1 の条件を参照するロジックは、最後に一致した条件に対してのみ機能しました。 v2 では、一致するすべての条件に対して動作するようにバック参照ロジックを構成できます。
  • 検索エンジンの最適化のルール テンプレート (RTW の新機能)。 3 つの新しいルール テンプレートを使用すると、サイト上の Web ページに対して正規 URL の使用を強制するリダイレクト ルールを簡単に作成できます。
  • リバース プロキシ ルール テンプレート (RTW の新機能)。 このテンプレートを使用すると、リバース プロキシ構成を実装する受信書き換え規則と送信書き換え規則を非常に迅速に生成できます。
  • 書き換えられた URL のログ記録。 書き換えルールは、最初に要求された URL をログに記録するのではなく、書き換えられた URL を IIS W3C ログに記録するように構成できます。
  • 更新された IIS マネージャーのユーザー インターフェイス。 モジュール構成をより適切に表現し、書き換えルールや書き換え条件の構成などの一般的なタスクを簡略化するために、ユーザー インターフェイスが大幅に改善されました。

モジュールのインストール

モジュールのホーム ページ (https://www.iis.net/extensions/urlrewrite) にあるリンクを使用して、URL Rewrite 2.0 をダウンロードします

Note

  • v1.0 や v1.1 などの以前のバージョンの URL Rewrite が既にインストールされている場合は、v2.0 にアップグレードされます
  • URL Rewrite 2.0 の RC バージョンが既にインストールされている場合は、RTW バージョンにアップグレードされます。

既知の問題

  1. 応答の書き換えは静的圧縮では機能しません。 応答の書き換えを使用するには、IIS の静的圧縮を無効にする必要があります。
  2. rewriteBeforeCache が有効になっている場合、アウトバウンド規則はチャンク転送でエンコードされた応答には適用されません。 チャンク転送エンコードされた応答を書き換える必要がある場合は、rewriteBeforeCache を false に設定します。

機能拡張サンプルのインストール

URL Rewrite 機能拡張サンプル には、.NET アセンブリと、これらのプロバイダーを実装するソース コードが含まれています:

  • DbProvider - このプロバイダーを使用して、ストアド プロシージャを実行することで、SQL Server データベース テーブルから書き換えマッピングを取得できます;
  • FileMapProvider - このプロバイダーを使用して、テキスト ファイルに格納されている書き換えマッピングを取得できます;
  • FileContainsProvider - このプロバイダーを使用して、テキスト ファイル内の文字列がプロバイダーの入力文字列の部分文字列であるかどうかを確認できます。

MSDN コード ギャラリーから URL Rewrite 機能拡張サンプル をダウンロードします。

モジュールの使用

これらの記事では、URL Rewrite v2.0 の機能について説明し、それを使用して一般的な URL 書き換えシナリオを達成する方法について説明します。

チュートリアル

機能リファレンス