ASP.NET と IIS 7 の統合

  • [アーティクル]

公開日: 2007 年 12 月 5 日 (作業者: IIS チーム (英語))

更新日: 2008 年 3 月 4 日 (作業者: IIS チーム (英語))

はじめに

ASP.NET は、そのリリース以来、Windows や IIS プラットフォームでの Web アプリケーション開発に最適なプラットフォームとしての地位を維持してきました。ASP.NET 2.0 によって、Web アプリケーション開発は新しい段階に引き上げられ、開発者はかつてないほどの速度でより強力なアプリケーションを開発できるようになりました。

IIS 7 では、ASP.NET ランタイム拡張機能モデルがコア サーバーと統合され、ASP.NET はさらに進化しています。この統合によって、開発者は下位レベルの IIS C++ API を使用する代わりに、ASP.NET 2.0 および .NET Framework の豊富な機能を使用して IIS 7 サーバーを 拡張できます。既存の ASP.NET アプリケーションも、フォーム認証、役割、出力キャッシュなどの既存の ASP.NET 機能をすべてのコンテンツ タイプで使用でき、より緊密な統合の恩恵をすぐに受けることができます。

IIS 7 の既定では、強化された ASP.NET 統合を利用できますが、他の選択肢も残っています。IIS 7 は新旧の両方の ASP.NET 統合モードをサポートし、これらを同一サーバー上で同時に使用できます。

この記事では、新しい ASP.NET 統合モードで導入された強化点、これら 2 つのモードのアーキテクチャ、各種 ASP.NET アプリケーションでの統合モードの選択および構成方法を説明します。

IIS 7 での ASP.NET の強化点

IIS 7 での ASP.NET 統合の強化によって、既存のアプリケーションが強化され、新しいアプリケーションに新しい手法で ASP.NET 機能の利点を活用できるようになります。

  • **すべてのコンテンツ タイプに使用可能な ASP.NET サービス。**従来、フォーム認証、役割、URL 認証、出力キャッシュなどは、ASPX ページなどの ASP.NET コンテンツ タイプでのみ使用可能でした。静的ファイル、ASP ページ、その他のコンテンツ タイプなどでは、これらのサービスの利点を活用できませんでした。

IIS 7 では、すべてのコンテンツに対して、すべての ASP.NET サービスが同様に提供されます。たとえば、ASP.NET フォーム認証、メンバーシップ、ログイン コントロールで構築した既存の ASP.NET 2.0 アクセス制御ソリューションを使用して、画像、ASP ページを含めたすべての Web コンテンツを保護できます。

  • **ASP.NET での IIS の完全な拡張。**IIS の過去のバージョンでは、ASP.NET のランタイムの制限があり、ネイティブ ISAPI フィルターや拡張子の拡張機能モードを使用したサーバー拡張機能の開発が必要になることが多くありました。

IIS 7 では、ASP.NET モジュールをサーバー パイプラインに直接接続でき、これにはネイティブ (C++) サーバー API で開発したモジュールと同じランタイム再現性があります。ASP.NET モジュールは、要求処理パイプラインのすべてのランタイム段階で実行でき、またネイティブ モジュールに対してどのような順番でも実行できます。ASP.NET API も拡張され、過去のバージョンより詳細に要求処理を制御できます。

  • 統合されたサーバー ランタイム。 ASP.NET の緊密な統合によって、IIS 7 と ASP.NET との間で多くの機能を統合することもできます。

IIS 7 では、IIS 構成と ASP.NET モジュールおよびハンドラーの構成が統合されています。カスタム エラー、トレースをはじめとする、その他多くの機能が統合され、管理の向上と、アプリケーション設計の統一が実現しています。

ASP.NET 統合アーキテクチャ

IIS 6 以前は、ASP.NET は ISAPI 拡張機能の 1 つとして実装されていました。

ASP.NET コンテンツ タイプに対する要求は、最初に IIS によって処理されてから、ASP.NET 要求パイプラインおよびページ フレームワークをホストする ASP.NET ISAPI DLL に送られました。ASP ページ、静的ファイルなどの非 ASP.NET コンテンツに対する要求は、IIS または他の ISAPI 拡張機能によって処理され、ASP.NET からは不可視でした。

このモデルの主な制限は、サービスが ASP.NET によって提供されているという点です。カスタム ASP.NET アプリケーション コードは、非 ASP.NET 要求に対しては使用できませんでした。さらに、ASP.NET 実行パスの前後で発生する IIS 要求処理の特定の部分では、ASP.NET モジュールは作用できませんでした。

Ff454024.fig1(ja-jp,TechNet.10).jpg 

図 1: IIS 6 および ASP.NET のパイプライン

IIS 7 では、ASP.NET 要求処理パイプラインが IIS パイプライン全体を直接覆っているので、事実上は、接続しているのではなくラッパーとなっています。

任意のコンテンツ タイプに対する要求は、全段階において、要求処理を提供できるネイティブ IIS モジュールおよび ASP.NET モジュールの両方を使用して、IIS 7 によって処理されます。これによって、ASP.NET モジュールで提供されるフォーム認証、出力キャッシュなどのサービスを、ASP ページ、PHP ページ、静的ファイルなどへの要求の処理に使用できます。

サーバー パイプラインに直接接続する機能によって、ASP.NET モジュールで任意の IIS 7 機能を置き換えたり、その前後に実行することができます。これによって、メンバーシップ サービスおよび SQL Server ユーザー データベースを使用するために記述したカスタム ASP.NET 基本認証モジュールを使用して、Windows アカウントに対してのみ動作する組み込みの IIS 基本認証機能を置き換えることなどが可能になります。

また、拡張された ASP.NET API では、直接的な統合の利点が活用され、より多くの要求処理タスクを実行できます。たとえば、ASP.NET モジュールは、他のコンポーネントが要求を処理する前に要求ヘッダーに変更を加えることができるので、ASP アプリケーションが実行される前に Accept-Language を挿入し、ユーザー設定に基づいてクライアントにローカライズ済みコンテンツを返すことなどが可能です。

Ff454024.fig2(ja-jp,TechNet.10).jpg 

図 2: IIS 7 の統合モード

ランタイム統合の結果、IIS 7 と ASP.NET は、サーバー モジュールの有効化と順序の決定、およびハンドラーのマッピングの構成用に、同じ構成を使用できます。その他、トレース、カスタム エラー、出力キャッシュが統合されています。

互換性

最も優れている点は、この統合アーキテクチャが既存の ASP.NET ランタイム アーキテクチャおよび API を保持しているので、既存の ASP.NET アプリケーションおよびサービスがそのまま動作することです。既存のアプリケーションにわずかな変更を加えるだけで、新しい ASP.NET 機能の利点を活用できます。

また、開発者は、ランタイム統合の利点を活用しながら、慣れ親しんだ ASP.NET API を使用して今後も新しいアプリケーションを記述できます。

IIS 7 では、統合モードで満たされない特定の互換性の要件を持つ ASP.NET アプリケーションのための、クラシック ASP.NET モードが引き続き提供されます。管理者は、アプリケーション プールごとに目的の統合モードを選択できるので、新しいモードを使用するアプリケーションとクラシック ASP.NET モードを使用するアプリケーションの両方を同一サーバー上で機能させることができます。

ASP.NET アプリケーションの IIS 7 統合モードへの移行

IIS 7 の既定では、ASP.NET は新しい統合モードで動作するように構成されます。これは、最小の変更で統合モードの強化点をアプリケーションで活用できるようにするためです。

構成の統合の結果、一部のアプリケーションでは統合モードで適切に動作させるために移行作業が必要になることがあります。既定では、移行の支援がサーバーから提供されます。サーバーは、移行が必要なアプリケーションを検出し、アプリケーションの移行を要求するエラー メッセージを返します。

以下の構成で、移行エラーが発生します。

  1. アプリケーションの web.config ファイルで <httpModules> 構成が定義されている。
    このアプリケーションは、新しい ASP.NET モジュールを読み込むか、既存のモジュールを削除します。
    統合モードでは、ASP.NET モジュールは、統合された <system.webServer>/<modules> 構成セクションに、ネイティブ モジュールと一緒に指定されます。
    <system.web>/<httpModules> 構成セクションに指定された ASP.NET モジュールを有効にするには、この新しい構成セクションに移動する必要があります。その後、新しい ASP.NET モジュールを <modules> セクションに直接追加する必要があります。
  2. アプリケーションの web.config ファイルで <httpHandlers> 構成が定義されている。
    このアプリケーションでは、いくつかのコンテンツ タイプでカスタム ハンドラー マッピングが使用されます。
    統合モードで ASP.NET ハンドラー マッピングを有効にするには、統合された <system.webServer>/<handlers> 構成セクションに指定する必要があります。その後、新しい ASP.NET ハンドラー マッピングを統合された <handlers> セクションに直接追加する必要があります。
    このセクションは、ASP.NET の <httpHandlers> 構成および IIS 7 スクリプトマップ構成の両方の代わりとなるものです。以前は、ASP.NET ハンドラー マッピングをセットアップするために、両方を構成する必要がありました。
  3. アプリケーションの web.config ファイルで <identity impersonate="true" /> 構成が定義されている。
    このアプリケーションは、クライアント資格情報を偽装します (イントラネット アプリケーションでよく使用されます)。統合モードでは、クライアント偽装は要求処理の初期のいくつかの段階で利用できません。ほとんどの場合、これは問題とならないのでエラーを止めることができます。問題となる場合は、このアプリケーションがクラシック ASP.NET モードで実行されるように構成する必要があります。

このエラーが生成された場合、アプリケーション構成を移行する (上記 1 番および 2 番の場合に推奨) か、アプリケーションでクラシック ASP.NET モードを使用するように変更 (上記 3 番の場合) します。

アプリケーション構成の移行

IIS 7 は、移行の実行に APPCMD.EXE コマンド ラインを使用してアプリケーションの移行を支援します。移行エラー メッセージには、アプリケーションをすぐに統合モードに移行できるようにするため、コマンド ライン ウィンドウで実行するコマンドが表示されます。コマンド ライン ウィンドウは、[すべてのプログラム] をクリックしてから [アクセサリ] をクリックし、[コマンド プロンプト] アイコンを右クリックして [管理者として実行] をクリックして起動する必要があります。

移行コマンドの基本的な形式は、次のとおりです。

%windir%\system32\inetsrv\APPCMD.EXE migrate config <アプリケーション パス>

ここで、<アプリケーション パス> はサイト名を含むアプリケーションの仮想パス (例: Default Web Site/app1) です。

移行が完了すると、アプリケーションは統合モードとクラシック モードの両方で問題なく実行できるようになります。

メモ: 移行後は、構成を変更しても、サーバーから再度移行要求が表示されることはありません。最初の移行の後は、APPCMD.EXE コマンド ライン ツールを使用して手動でアプリケーションを再度移行し、構成が両方のモードで動作するよう確認する必要があります。

クラシック ASP.NET モードに戻す

クラシック ASP.NET モードに戻すには、クラシック モードで実行するように構成されたアプリケーション プールにアプリケーションを移動します。他のアプリケーションは引き続き新しい統合モードで実行され、クラシック モード アプリケーションと共存できます。

アプリケーションをクラシック ASP.NET モードに移行する方法については、「アプリケーションの ASP.NET モードの変更」を参照してください。

移行エラー メッセージの無効化

手動で構成を移行した場合、または構成を移行せずに統合モードを使用する (非推奨) 場合は、アプリケーションの web.config ファイルに次のコードを追加して、移行エラー メッセージを無効にできます。

<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
</system.webServer>

メモ: APPCMD.EXE コマンド ライン ツールを使用して構成を移行した後は、このエラー メッセージはサーバーで自動的に無効になります。

移行エラー メッセージを手動で無効にする場合は、前述のサポートされない構成についての警告がサーバーから通知されなくなるので、アプリケーションが統合モードで正しく動作することを確認する必要があります。

アプリケーションの ASP.NET モードの変更

アプリケーションが統合 ASP.NET モードで正しく動作しない場合、クラシック ASP.NET モードに移行します。アプリケーションを他のアプリケーション プールに移動するだけで移行を実行できます。各アプリケーション プールは、目的の ASP.NET 統合モードを使用するように個別に構成されています。こうすることで、異なる ASP.NET 統合モードを使用するアプリケーションのグループを同一サーバー上で実行できます。

アプリケーションの ASP.NET 統合モードを変更するには、次の手順に従ってください。

  1. 目的のモードを使用するように構成されているアプリケーション プールを見つけるか、作成します。
    既定では、システムに新しく作成したアプリケーション プールはすべて統合モードで実行されます。
    ASP.NET セットアップでは、クラシック ASP.NET 統合モードで実行される "Classic .NET AppPool" という名前のアプリケーション プールが作成されます。統合モードで実行しないアプリケーション用に、このアプリケーション プールを使用できます。
    既存のアプリケーション プールの ASP.NET モードを変更することもできます。変更するには、IIS 7 の管理ツール、および APPCMD.EXE コマンド ライン ツールを使用するか、アプリケーション プールの構成を手動で編集します。
  2. そのアプリケーション プールを使用するアプリケーションを設定します。
    各アプリケーションは、特定のアプリケーション プールを使用するように構成されます。既定では、すべてのアプリケーションは、統合モードで実行される "DefaultAppPool" という名前の既定のアプリケーション プールを使用します。
    アプリケーションが属するアプリケーション プールを変更することもできます。変更するには、IIS 7 の管理ツール、および APPCMD.EXE コマンド ライン ツールを使用するか、アプリケーションの構成を手動で編集します。

アプリケーションの ASP.NET バージョンの選択

IIS はこれまで、ASP.NET および CLR の複数のバージョンの共存をサポートしてきました。たとえば、同一サーバー上で、.NET Framework Version 1.1 を使用する ASP.NET アプリケーションと Version 2.0 を使用する ASP.NET アプリケーションの両方を実行できます。これがサポートされているのは、IIS 7 スクリプトマップ構成を使用して、ASPNET_isapi.dll の対応バージョンをマッピングし、ASP.NET コンテンツの要求を処理するようにしていたからです。

たとえば、以下のスクリプトマップ構成を使用して共存できます。

  1. /app1 の ASP.NET Version 1.1 アプリケーション:
    *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll
  2. /app2 の ASP.NET Version 2.0 アプリケーション:
    *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll

アプリケーションに *.aspx 要求が到着すると、IIS 7 は指定された aspnet_isapi.dll を読み込みます。この DLL は、正しい CLR バージョンをワーカー プロセスに読み込んで要求を処理します。

ASP.NET では、以下の方法でも共存スクリプトマップを構成できます。

  1. **ASP.NET MMC 拡張。**使用する ASP.NET バージョンをユーザーが選択すると、この拡張機能によって、アプリケーションで正しい aspnet_isapi.dll バージョンを使用するように自動的にスクリプトマップが構成されます。
  2. **ASP.NET aspnet_regiis.exe。**ユーザーが -i および -r オプションを使用して、対応する ASP.NET バージョンを指すスクリプトマップをインストールします。

単一のワーカー プロセスには 1 つの CLR バージョンのみ読み込むことができるという制限があるので、異なるバージョンを使用する 2 つのアプリケーションが同じアプリケーション プールに存在しないように、構成に注意する必要があります。これはよくある間違いです。最初の要求では対応する aspnet_isapi.dll の CLR が読み込まれますが、この後で同じアプリケーション プール内で別のバージョンに要求が送られると失敗します。

IIS 7 では、アプリケーション プールは ASP.NET のバージョン管理の単位として認識されます。そのため、アプリケーション プールに読み込まれる CLR および ASP.NET のバージョンは、アプリケーション プール構成で明示的に構成されています。既定では、バージョンが空でない限り、ワーカー プロセスを読み込むときに、IIS 7 はこの設定で指定されている CLR を事前に読み込みます。

アプリケーション プールは .NET Framework のバージョン管理境界なので、ASP.NET アプリケーションのバージョン変更の選択肢は以下のようになります。

  1. 目的の ASP.NET バージョンを使用するアプリケーション プールにアプリケーションを移動する。
    既定では、アプリケーションは、統合モードで ASP.NET Version 2.1 が実行される "DefaultAppPool" という名前の既定のアプリケーション プールを使用します。ASP.NET Version 2.1 クラシック モードで実行するには "Classic .NET AppPool"、またはその他のアプリケーション プールを選択して、アプリケーションを移動します。
  2. アプリケーションが含まれているアプリケーション プールを構成し、目的の ASP.NET バージョンを使用するように設定する。
    既定では、新しく作成したアプリケーション プールはすべて、統合モードで ASP.NET Version 2.1 を実行するように構成されます。

メモ: 特定のアプリケーションまたはすべてのアプリケーションの ASP.NET バージョンの構成には、aspnet_regiis /i または /r オプションを使用しないでください。

IIS 7 では、アプリケーション プールに構成された CLR バージョンおよびマネージ統合モードに基づいて、正しいハンドラー マッピングのセット (クラシック モードでは ASPNET_isapi.dll、統合モードでは直接マネージ ハンドラー タイプにマッピング) を自動的に選択するために、必須ハンドラー マッピングが使用されています。ASP.NET 2.0 セットアップで、これらのハンドラー マッピングがサーバー レベルでインストールされます。

統合 ASP.NET モードの利点の活用

IIS 7 の既定では、ASP.NET アプリケーションは統合モードで実行されます。ただし、緊密な統合の恩恵を受けるには、アプリケーション構成に少し変更を加える必要があります。また、統合モードの利点を活用してアプリケーションに強力な機能を追加する新しい ASP.NET コンポーネントを開発することもできます。

すべてのコンテンツ タイプに対する ASP.NET サービスの有効化

統合モードでは、ASP.NET モジュールが提供するサービスは、すべてのコンテンツ タイプに対する要求に使用できます。しかし、既定では後方互換性を維持するために、ASP.NET モジュールは ASP.NET コンテンツの要求に対してのみ実行されるように構成されます。

これには、サーバー レベルの構成セクションで、各 ASP.NET モジュールに対して preCondition="managedHandler" を指定します。

<modules> 
     <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" 
             preCondition="managedHandler" />
     <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" 
             preCondition="managedHandler" />
    ...
</modules>

この前提条件 (preCondition) は、サーバーが各要求を評価してモジュールを実行するかどうかを判断するための規則です。managedHandler 前提条件は、ASP.NET にマッピングされているコンテンツ タイプに対してのみ true になります。

ASP.NET モジュールで提供される機能をすべての要求に適用するには、モジュール エントリを削除し、アプリケーションのルートの web.config に前提条件なしで再度追加します。

<modules> 
    <remove name="FormsAuthentication" /> 
     <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" /> 
    '
</modules>

この変更を行うと、アプリケーション内のすべての要求に対して FormsAuthentication モジュールが実行されます。その結果、フォームに基づく認証を使用して、アプリケーションのすべてのコンテンツを保護できます。統合モードを活用して、アプリケーションのすべてのコンテンツに対してフォームに基づく認証を提供する方法については、統合パイプライン モードを活用するチュートリアルの記事を参照してください。

managedHandler 前提条件にかかわらず、アプリケーション内のすべての要求に対してすべてのマネージ (ASP.NET) モジュールが実行されるようにする簡単な方法もあります。各モジュール エントリから preCondition="managedHandler" を削除することなく、すべてのマネージ モジュールがすべての要求に対して実行されるようにするには、<modules> セクションの runAllManagedModulesForAllRequests プロパティを使用します。

<modules runAllManagedModulesForAllRequests="true" />

これを使用すると、"managedHandler" 前提条件の効果がなくなり、すべてのマネージ モジュールがすべての要求に対して実行されます。

他の ASP.NET モジュールを有効にしてアプリケーション全体に適用されることを試してください。たとえば、ASP.NET 出力キャッシュ モジュールを使用した ASP ページの出力キャッシュ、URL 認証およびロール マネージャーを使用した写真のアクセス制御規則の構成などを試したり、Web サイト全体で ASP.NET を利用する独自のモジュールを開発します。

さらに強力な ASP.NET サービスの構築

統合モードでは、ASP.NET モジュールはすべてのコンテンツにサービスを適用します。また、ASP.NET モジュールは統合モードでは統合された要求処理パイプラインで実行されるので、ネイティブ サーバー モジュールと同じ要求処理段階に登録され同じタスクを実行します。同時に、ASP.NET API の大部分が同じままなので、いくつかの重要な追加を行うことで、以前は利用できなかった機能を利用できるようになります。

ランタイム再現性

統合モードでは、ASP.NET の要求処理段階はモジュールから可視であり、IIS 7 パイプラインの対応する段階に直接接続されます。完全なパイプラインには以下の段階が含まれ、ASP.NET で HttpApplication イベントとして示されます。

  1. BeginRequest。要求処理が開始されます。
  2. AuthenticateRequest。要求が認証されます。IIS 7 および ASP.NET の認証モジュールは、この段階に登録されて認証を実行します。
  3. PostAuthenticateRequest
  4. AuthorizeRequest。要求が承認されます。IIS 7 および ASP.NET の承認モジュールは、認証されたユーザーが要求リソースに対するアクセス権を持っているかどうかを確認します。
  5. PostAuthorizeRequest
  6. ResolveRequestCache。キャッシュ モジュールは、この要求に対する応答がキャッシュ内に存在するかどうかを確認し、実行パスの残りに進まずに応答を返します。ASP.NET 出力キャッシュおよび新しい IIS 7 出力キャッシュの両方ともここで実行されます。
  7. PostResolveRequestCache
  8. MapRequestHandler。この段階は ASP.NET 内部のもので、要求ハンドラーの決定に使用されます。
  9. PostMapRequestHandler
  10. AcquireRequestState。要求の実行に必要な状態が取得されます。ASP.NET セッション状態、およびプロファイル モジュールは、ここでデータを取得します。
  11. PostAcquireRequestState
  12. PreExecuteRequestHandler。ハンドラーの実行前のあらゆるタスクがここで実行されます。
  13. ExecuteRequestHandler。要求ハンドラーがここで実行されます。ASPX ページ、ASP ページ、CGI プログラム、静的ファイルはここで処理されます。
  14. PostExecuteRequestHandler
  15. ReleaseRequestState。ここで要求状態の変化が保存され、状態が消去されます。ASP.NET セッション状態およびプロファイル モジュールは、この段階を使用して消去を行います。
  16. PostReleaseRequestState
  17. UpdateRequestCache。将来の使用のために、ここで応答がキャッシュに格納されます。ASP.NET 出力キャッシュおよび IIS 7 出力キャッシュ モジュールはここで実行され、キャッシュに応答を保存します。
  18. PostUpdateRequestCache
  19. LogRequest。この段階で、要求の結果がログに保存されます。エラーが発生した場合でも実行が保証されます。
  20. PostLogRequest
  21. EndRequest。この段階で、要求の最終の消去が実行されます。エラーが発生した場合でも実行が保証されます。

慣れ親しんだ ASP.NET API を使用して IIS 7 モジュールと同じ段階で実行できるので、以前はネイティブ ISAPI フィルターおよび拡張機能でのみアクセスできたタスクに、マネージ コードでアクセスできるようになりました。

たとえば、以下の処理を実行するモジュールを記述できます。

  1. 何らかの処理が行われる前に要求を傍受し、URL の書き換え、セキュリティ フィルター処理などを実行する。
  2. 組み込みの認証モードを置き換える。
  3. 受信する要求のコンテンツ (要求ヘッダーなど) を変更する。
  4. すべてのコンテンツ タイプで、送信する応答をフィルター処理する。

カスタム ASP.NET 認証モジュールを使用して IIS 7 を拡張する優れた例が、.NET による IIS 7 のモジュールの開発についての記事に記載されています。

拡張された ASP.NET API

ASP.NET API は過去のリリースとの後方互換性を維持しています。その結果、既存のモジュールが変更なしで IIS 7 で動作し、コード変更なしですべてのアプリケーション コンテンツに適用できるようになっています。

IIS 7 統合モード用に記述されたモジュールでは、いくつかの追加 API を活用して、以前は利用できなかった主要な要求処理シナリオを実行できます。

新しい HttpResponse.Headers コレクションで、他のアプリケーション コンポーネントが生成した応答ヘッダーをモジュールで検査したり変更することができます。たとえば、ASP ページが生成した Content-Type ヘッダーを変更して、ブラウザーにダウンロード ダイアログ ボックスを表示できます。HttpResponse クラスの Cookies コレクションも強化され、応答処理の一環として生成された Cookie を (ASP.NET 外で作成されたものであっても) 変更できます。

HttpRequest.Headers コレクションは書き込み可能で、受信する要求ヘッダーをモジュールで変更できます。これを使用して、他のサーバー コンポーネントの動作を変更できます。たとえば、Accept-Language ヘッダーの値を動的に変更し、異なる言語のクライアントに対してローカライズされたアプリケーションが応答を返すようにできます。

最後に、HttpRequest.ServerVariables コレクションが書き込み可能になり、IIS 7 サーバー変数を設定できるようになりました。この機能を使用する ASP.NET モジュールは、IIS 7 から提供された値を変更し、新しいサーバー変数を作成して PHP などの他のアプリケーション フレームワークで使用することができます。

ランタイム統合

統合モードでは、これらの新しい API に加えて、既存の ASP.NET 機能でアプリケーションに高い価値を付加できます。

System.Diagnostics.Trace クラス、ASP.NET ページ トレース機能をはじめとする、ASP.NET で提供されるトレース機能で、IIS 7 のトレース システムにトレース情報を送ることができるようになりました。これによって、IIS 7 および ASP.NET のコンポーネントの両方の要求処理で生成されたトレース情報を単一のログ ファイルに記録できるようになり、サーバーの問題を診断しやすくなりました。

応答をクライアントに返す前にストリーム インターフェイス経由で変更する ASP.NET の応答フィルター処理機能が強化され、非 ASP.NET コンテンツをフィルター処理できるようになりました。この結果、ASP.NET のフィルター処理をすべてのサーバー コンテンツに使用したり、処理が必要なコンテンツに対する要求のみにフィルターを選択的にインストールすることができます。この機能を使用すると、コンテンツが ASPX ページからのものか、静的ファイルからのものかに関係なく、サイトの応答に特定のコンテンツを挿入したり検閲するフィルター処理機能を記述できます。

まとめ

IIS 7 での ASP.NET 統合によって、ASP.NET の可能性が完全に引き出され、開発者は簡単に機能豊富な ASP.NET および .NET Framework を使用して、強力なサーバー コンポーネントを作成できます。既存のアプリケーションで ASP.NET 統合モードを活用する方法については、統合パイプライン モードの活用方法についての記事を参照してください。サーバーを拡張するための新しい ASP.NET コンポーネントの構築方法については、.NET による IIS 7 のモジュールの開発についての記事を参照してください。

関連コンテンツ

記事