次の方法で共有


IIS URL 書き換えと ASP.NET ルーティング

作成者: Ruslan Yakushev

IIS 用の URL 書き換えモジュールがリリースされ、ASP.NET ルーティングが .NET Framework 4 に組み込まれたことにより、ASP.NET 開発者から、これら 2 つの機能が相互にどのように関連しているのか、また、どのような場合にどちらの方法を使用する必要があるのかについて多くの質問が寄せられました。 このドキュメントでは、これら 2 つのテクノロジの違いについて説明し、IIS URL 書き換えを使用する場合と、ASP.NET ルーティングを使用する場合について Web 開発者向けのガイダンスを提供します。

大まかな観点から見ると、これらのテクノロジは非常によく似た機能を提供しているように見えます。どちらを使用した場合も、Web アプリケーションで、URL をユーザー フレンドリで検索エンジン フレンドリなものにすることができます。 ただし、これら 2 つのテクノロジには、Web アプリケーションにどのテクノロジを使用するかを的確に判断する上で重要となる根本的な違いがあります。 これらの違いを理解できるように、最初に IIS URL 書き換えと ASP.NET ルーティングのしくみについて説明します。

IIS URL 書き換え

URL 書き換えの基本的な考え方は新しい概念ではありません。 これは約 10 年前に Apache Web サーバーで導入されました。 それ以来、Web サーバー管理者や Web 開発者にとって非常に便利なツールであることが証明されています。 Apache でホストされている一般的なアプリケーションの多くは、"クリーンな" URL のサポートを可能にするために URL 書き換えに依存するようになりました。

URL 書き換えの概念は単純です。 クライアントから Web サーバーに特定の URL の要求が送信されると、URL 書き換えモジュールによって、要求された URL が分析され、同じサーバー上の別の URL に変更されます。 URL 書き換えモジュールは、要求処理パイプラインの早い段階で実行され、要求の処理に使用するハンドラーが Web サーバーで決定される前に、要求された URL を変更します。 ハンドラーは、書き換えられた URL に基づいて選択され、要求を処理し、Web ブラウザーに送り返される応答を生成します。 要求側のクライアントが書き換えられた URL を認識することはありません。クライアントとしては、元の URL から応答を受信したことになります。

IIS アーキテクチャの観点から見ると、このプロセスは次の図で表されます。

Diagram of the I I S U R L Rewriting process from the H T T P Request to the H T T P Response.

URL 書き換えモジュールは、開始前要求または開始要求のステージで要求処理パイプラインにプラグインされ、一連の書き換えルールを使用して、要求された URL パスを評価するネイティブ コード モジュールです。 各書き換えルールは、URL パスを分析し、すべてのルール条件が満たされた場合に元のパスを新しいパスに変更します。 すべてのルールが評価された後、URL 書き換えモジュールによって、残りの IIS パイプライン処理で要求に使用される最終的な URL パスが生成されます。 つまり、IIS パイプラインでは、URL 書き換えモジュールによって生成される書き換え済みの URL に基づいてハンドラーが選択されます。

ASP.NET ルーティング

ASP.NET ルーティングは、開発者が特定の URL を、その URL に対する要求を処理できるハンドラーに関連付けることができる要求ディスパッチ メカニズムです。 この関連付けは、特定の URL パスに対してどのハンドラーを呼び出すかを定義する "ルート" を登録することによって行われます。 Web サーバーに対して要求が行われると、ASP.NET ルーティングでは、登録されたルートの一覧内で要求された URL パスを検索します。 ルートが見つかると、そのルートに対応するハンドラーが呼び出され、その要求が処理されます。

IIS と ASP.NET のアーキテクチャの観点から見ると、このプロセスは次の図で表されます。

Diagram of the A S P dot NET routing process using I H T T P Handlers from Request to Response.

ASP.NET ルーティングは、キャッシュの解決ステージ (PostResolveRequestCache イベント) およびマップ ハンドラー ステージ (PostMapRequestHandler イベント) で IIS 要求処理パイプラインにプラグインされるマネージ コード モジュールとして実装されます。 ASP.NET ルーティングは、Web アプリケーションに対して行われたすべての要求に対して実行するように構成されます。

PostResolveRequestCache イベント中に、モジュールはルーティング テーブル (ルート オブジェクトのコレクション) を調べて、要求された URL パスに一致するルートを見つけます。 一致するものが見つかると、モジュールはそのルートに対応するハンドラーへの参照を取得し、その参照を現在の HTTP コンテキストの一部として保存します。 ハンドラーには、System.Web.IHttpHandler インターフェイスを実装する任意の .NET Framework オブジェクトを指定できます。 ルートが見つからない場合、モジュールは何も行わず、URL は失敗し、通常どおり処理されます (通常はディスク上のファイルと照合されます)。

PostMapRequestHandler イベント中に、モジュールは HTTP コンテキストにハンドラーに関する情報が含まれているかどうかを確認します。 情報が含まれている場合、ASP.NET ルーティングはその情報を使用して、現在の HTTP コンテキストの Handler プロパティを設定します。 これにより、ハンドラーの実行ステージ中に、ルーティング モジュールによって選択されたハンドラーが IIS によって実行されることが保証されます。 この情報が設定されていない場合、モジュールは何も行わず、URL は失敗し、IIS によってハンドラーが選択されることになります。

IIS URL 書き換えと ASP.NET ルーティングの違い

上記の説明に基づくと、IIS URL 書き換えと ASP.NET ルーティングの間には、主に次のような概念上の違いがあります。

  1. URL 書き換えは、要求が Web サーバーによって処理される前に URL パスを操作するために使用されます。 URL 書き換えモジュールは、書き換えられた URL を最終的にどのハンドラーが処理するかを認識しません。 さらに、実際の要求ハンドラーは、URL が書き換えられたことを認識しない場合もあります。
  2. ASP.NET ルーティングっは、要求された URL パスに基づいてハンドラーに要求をディスパッチするために使用されます。 URL 書き換えとは対照的に、このルーティング モジュールはハンドラーを認識し、要求された URL に対する応答を生成する必要があるハンドラーを選択します。 ASP.NET ルーティングは、高度なハンドラー マッピング メカニズムと考えることができます。

これらの概念上の違いに加えて、IIS URL 書き換えと ASP.NET ルーティングの間には次のような機能上の違いがあります。

  1. IIS URL 書き換えモジュールは、ASP.NET、PHP、ASP、静的ファイルなど、あらゆる種類の Web アプリケーションで使用できます。 ASP.NET ルーティングは、.NET Framework ベースの Web アプリケーションでのみ使用できます。
  2. IIS URL 書き換えモジュールは、アプリケーション プールに統合 IIS パイプライン モードまたはクラシック IIS パイプライン モードのどちらが使用されているかに関係なく、同じように動作します。 ASP.NET ルーティングの場合は、統合パイプライン モードを使用することをお勧めします。 ASP.NET ルーティングはクラシック モードでも動作しますが、その場合、アプリケーションの URL にファイル名拡張子を含めるか、IIS で "*" ハンドラー マッピングを使用するようにアプリケーションを構成する必要があります。
  3. IIS URL 書き換えモジュールは、ドメイン名、HTTP ヘッダー、サーバー変数に基づいて書き換えを決定できます。 既定では、ASP.NET ルーティングは URL パスと HTTP-Method ヘッダーでのみ機能します。
  4. URL 書き換えモジュールは、書き換えに加えて、HTTP リダイレクトの実行、カスタム状態コードの発行、要求の中止を行うことができます。 ASP.NET ルーティングはこれらのタスクを実行しません。
  5. URL 書き換えモジュールは、現在のバージョンでは拡張できません。 ASP.NET ルーティングは完全に拡張でき、カスタマイズできます。

どちらのオプションを使用する必要があるか

Web アプリケーションでクリーンな URL を有効にするテクノロジを選択する必要がある場合、この情報はいったい何を意味するのでしょうか? このセクションでは、この選択を行う方法について説明します。

Web アプリケーションが ASP.NET 以外のものを使用して構築されている場合、IIS URL 書き換えモジュールを使用します。 それ以外の場合のルールは、次のとおりです。

  1. ASP.NET MVC または ASP.NET 動的データ テクノロジを使用する新しい ASP.NET Web アプリケーションを開発している場合は、ASP.NET ルーティングを使用します。 アプリケーションは、Web ページ内のリンクのクリーンな URL の生成など、クリーンな URL のネイティブ サポートの恩恵を受けることができます。 ASP.NET ルーティングは、標準の Web Forms アプリケーションをまだサポートしていないことに注意してください。ただし、将来的にはサポートされる予定です。
  2. レガシー ASP.NET Web アプリケーションが既にあり、それを変更したくない場合は、URL 書き換えモジュールを使用します。 URL 書き換えモジュールを使用すると、検索エンジン フレンドリな URL を、アプリケーションで現在使用されている形式に変換できます。 また、検索エンジン クローラーをクリーンな URL にリダイレクトするために使用できるリダイレクト ルールを作成することもできます。

ただし、実際の選択は二者択一ではありません。 これらのテクノロジは、組み合わせて使用することができ、相互に補完できます。 以降のセクションでは、ASP.NET ルーティングと IIS URL 書き換えを併用できるいくつかのシナリオについて概説します。

アプリケーションに対する正規 URL の強制。
http://mysite.com/Home/About の代わりに http://www.mysite.com/home/about を強制的に使用する必要があります。 Web クライアントが必要な形式に準拠していない URL を要求すると、クライアントは正規 URL にリダイレクトされます。 このシナリオでは、URL 書き換えモジュールを使用して正規 URL を強制して、リダイレクトを実行し、ASP.NET ルーティングを使用して、要求された 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>

別のサイトまたはサーバーからの静的コンテンツの提供。
Web アプリケーションは、動的 Web コンテンツが 1 つのサイトまたはサーバーに配置され、すべての静的コンテンツが別のサイトまたはサーバーに配置されるように、複数のサーバーにデプロイされます。 URL 書き換えモジュールを IIS アプリケーション要求ルーティング モジュールと組み合わせて使用すると、静的ファイルの要求のすべてを別のサーバーに転送しながら、現在のサーバーからの動的 Web ページの要求をすべて処理できます。 このように、ASP.NET ルーティングは動的 Web コンテンツにのみ使用され、静的コンテンツの URL を評価しません。

次の例は、このシナリオに使用できる 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 をサポートできます。 実際、ファイルまたはフォルダーが移動されたことを Web サイト訪問者に知られたくない場合があります。 その場合、URL 書き換えモジュールを使用して静的ファイルのパスを書き換えることができ、動的 ASP.NET Web ページへのすべての URL はルーティング モジュールによって処理されます。

次の例は、このシナリオに使用できる URL 書き換えルールを示しています。

<rewrite>
    <rules>
        <rule name="Rewrite to new folder">
            <match url="^Images/(.+)$" />
            <action type="Rewrite" url="NewImages/{R:1}" />
        </rule>
    </rules>
</rewrite>

要求のブロック
URL 書き換えモジュールを使用すると、さまざまな条件に基づいて特定の要求をブロックできます。 たとえば、特定のサイト クローラーが Web サイト上の特定の URL パスにアクセスできないようにすることができます。 こうすることで、禁止された要求が ASP.NET ルーターに到達することさえなくなり、Web サーバーの負荷が軽減されます。

次の例は、不要なサイト クローラーをブロックするために使用できる URL 書き換えルールを示しています。 要求は、ユーザー エージェントの HTTP ヘッダーまたはクライアントの IP アドレスに基づいて、特定の URL パスに対してブロックされることに注意してください。

<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 ルーティングには機能的に重複する部分がありますが、各テクノロジに固有のシナリオに対処します。 そのため、これら 2 つのテクノロジは IIS 内の独立したコンポーネントとして引き続き存在し、進化を続けながら、これらの間でより緊密な統合が行われる可能性があります。 たとえば、ASP.NET ルーティングでは、URL 書き換えモジュールで提供される豊富なツールの一部を利用できます。 URL 書き換えモジュールは、URL 書き換えロジックをカスタマイズするための拡張性を提供するという点で、ASP.NET との統合を強化できます。

まとめ

IIS URL 書き換えまたは ASP.NET ルーティングのいずれかを使用して、Web アプリケーションの URL 操作シナリオを実装できます。 ASP.NET ルーティングは、ASP.NET 用に最適化されたソリューションであるため、ASP.NET アプリケーションを最初から設計し、クリーンな URL 構造を求める Web 開発者にとって望ましいソリューションになる可能性があります。 IIS URL 書き換えは、多数のシナリオに対処する汎用の URL 操作メカニズムです。 特に、Web 開発者だけでなく Web サーバーまたは Web サイト管理者もこれを使用すると、アプリケーション コードを変更することなく、既存の Web アプリケーションに対してクリーンな URL を有効にすることができます。