IIS Insider

ASP (Active Server Pages) の Response.buffer に関してよく知らない方にとっては、Response.buffer は、True に設定されている際、（IIS 5 および 6 では既定で True に設定されます） 全体の ASP ページの実行が完了するまで、プロパティにより ASP がスクリプトのレンダリングからの結果を送信しなくなります。少数のアプリケーションでは、response.buffer が、True に設定されていると、ページの作成が完了するまで、ユーザーに情報が送られないため、アプリケーションの速度が遅く見える場合があります。長い時間実行されているページまたは、データ ソースからデータを取得し、その後情報を戻すループを持つページは、この動作が起こるコードの例です。このような問題の解決策の 1 つに、Response.buffer を False に設定することがあります。ユーザーは、ページ全体が完成するのを待たずに、レンダリング中の情報を見ることができます。

Response.buffer を False に設定する事が良い状況はあまり多くないということを明確にしたいと思います。その設定をする前に、ページのプロセスが終了していないときに即座に必要な情報を待っているアプリケーションがある場合、 Response.Flush メソッドを使用して、クライアントにコンテンツを渡すことを考慮するべきです。Response.Flush を使用すると、バッファを有効にしておくことができますが、応答のバッファを正確にクライアントに送信されるように、正しくコントロールしてください。

これらをすべて説明した後、今回の報告中の動作は、Response.buffer が False に設定されているとき、クライアントの TCP/IP 接続が切断するというのは、実際には IIS 6 のバグです。TCP/IP 接続は本来切断されず、Product Support Services (PSS) から利用可能な更新プログラムで修正することができます。詳細は、http://support.microsoft.com/default.aspx?scid=kb;ja;834027&sd=tech で説明されています。(または Windows Server 2003 向けのサービス パック 1 がリリースされた場合、この修正が含まれている予定です。)

ASP.NET のこれらのトピックに関する説明は、http://msdn.microsoft.com/library/en-us/dnpag/html/scalenetchapt06.asp をご覧ください。この更新プログラムは、ASP を使用している場合にのみ適用されます。(ASP.NET には適用されません)

これは、セキュリティ上の問題である可能性があり、ご使用のすべての IIS サーバーを調べる必要があります。既定で、IIS 4、5 または 6 では、以下のような文字列を含むクライアント リクエストに応答します。

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://10.1.1.1/Default.htm
Date: Thu, 18 Feb 1999 14:03:52 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Wed, 06 Jan 1999 18:56:06 GMT
ETag: "067d136a639be1:15b6"
Content-Length: 4325

おっしゃるように、この例ではサーバーの IP アドレスが表に出ています。これは、サーバーの IP アドレスが NAT デバイスの背後のプライベート ネットワークまたはリバース プロキシ上にあるという多くの状況下では、好ましくありません。その理由は、攻撃者となる可能性のある人物にネットワーク構造に関する情報を与えてしまうことになるためです。

この状況を修正するには、いくつかの選択肢があります。IIS 5 (および IIS 4) では、メタベース プロパティ W3SVC\UseHostName プロパティを True に設定します。この変更を有効にするには、IIS を終了し、起動する必要があります。

IIS 6 では、Windows Server 2003 SP1 がリリースされるまで、PSS からリリースされる修正プログラムが必要となります。http://support.microsoft.com/default.aspx?scid=kb;ja;834141&sd=tech に、サポートのお問い合わせ先などを含む IIS 6 の修正プログラムに関する詳細が記載されています。

ユーザーが、サーバーの ＩＰ アドレスを見られないようにする他の方法として、静的な HTML ページ (.htm または .html) ではなく、ASP または ASP.NET を使用し、特定のコンテンツ ロケーション フィールドを返すカスタム ヘッダを作成することがあります。

IIS 4、5、および 6.0 では、Web サイトを設定し、ホスト ヘッダを使用してコンテンツのすべてのリクエストを二応答するようにすることができます。ホスト ヘッダが Web 上で使用されると、サーバーの IP アドレスは、コンテンツ ロケーション フィールドに戻されません。ホスト ヘッダ名を使用して、1 つの IP アドレスから複数のサイトをホストする方法に関する詳細は、マイクロソフト サポート技術情報 http://support.microsoft.com/default.aspx?scid=kb;ja;190008&sd=tech をご覧ください。

サイト ID は、IIS が内部で使用し、Web サイトを一意に識別する番号です。言い換えると、Web サイトを作成する際、“Accounting Intranet” などの名前をつけますが、IIS ではその名前はまったく使用されません。その代わり、サイト ID と呼ばれる番号が、Web サイトに割り当てられます。サイト ID および Web サイトの設定を構成する他のプロパティおよび値は、メタベースに保存され、自動的に保持されます。

多くの IIS 管理者にとって、サイト ID を最初に使用するのは、Web サイトのログファイルを検索する際です。図 1 は IIS 6 サーバーの IIS ログ ファイルのロケーションを示します。

図 1: IIS 6 サーバー上の IIS ログ ファイルのロケーション
拡大表示する

ログ ファイル名は “W3SVC” プラス サイト ID です。これは、IIS 5 および IIS 6 に当てはまります。ログ ファイル フォルダの一覧 （図 2 参照） から、関連の Web サイトの名前を識別することができますか?

図 2: ログ ファイル フォルダの一覧

一般的に、この答えは、既定の Web サイトの “W3SVC1” 以外は No です。

また、サイト ID も知る必要があるもう 1 つの理由は、スクリプトのためです。スクリプトに関しては、この IIS Insider のコラムで扱うには、大きすぎるトピックなのですが、ここでは、短くまとめてお話したいと思います。

ファイル名 (C:\<ディレクトリ>\<ファイル名>) へのパスがあるように、メタベース (W3SVC\<サイト ID>\<プロパティ名>) のロケーションへのパスがあります。たとえば、Web サイト名が既定の Web サイトのメタベースに保存されるロケーションを参照する場合、それは W3SVC/1/ServerComment となります。スクリプトまたは ADSUTIL (英語) を使用して、メタベースの値のクエリを行うか、または変更することができます。メタベースに関する詳細は、http://www.microsoft.com/resources/documentation/IIS/6/all/techref/en-us/iisRG_ARC_8.mspx (英語) をご覧ください。

この理由および他の理由 (スクリプトを記述してメタベースのプロパティを編集するなど) により、特定の Web サイトとそのサイト ID を関連付ける方法を知る必要があります。

IIS 5 でインターネット サービス マネージャ コンソールでこれを行う最も容易な方法は、ロギング プロパティ ウインドウで行うことです。(図 1 参照) IIS 6 では、インターネット インフォメーション サービス マネージャにサイト名および IP アドレスと共に表示されます。(図 3 参照)

図 3: IIS 6 のインターネット インフォメーション サービス マネージャ
拡大表示する

サイト ID がどのようなものかお分かりになったと思いますが、サイト ID およびサイト ID に Web サイトと関連付ける方法を知る必要がある理由は何でしょうか? またこの疑問に戻ってきました。

お気づきのように、IIS 5 では、サイト ＩD は、順番に作成されます。一方 IIS 6 は、大きな数字の一見乱数と見えるサイト ＩD を作成します。しかし、この不規則性にもメソッドがあります。IIS 6 のサイト ID は、Web サイト名から生成されます。“Accounts Receivable Intranet” というサイトを作成し、そのサイトを削除し、再度作成する場合、同じサイト ID が割り当てられるのです！ IIS 5 では、そうなりません。それぞれのコンテンツの複製を持つ複数のサーバーが存在する Web ファームをもつ IIS ユーザー向けに特定の機能が作成されました。このように、同じ Web サイトの場合、ファームのすべての Web サイトのサイト ID は同じです。たとえば、ファームに 3 つの IIS 6 サーバーがある場合、“Company Extranet” という名前の Web サイトをもつすべてのサーバーでは、3 つのサーバーすべてでサイト ID が同じとなります。これにより、同じファイルおよび ADSI パスにそれぞれログファイルおよび IIS メタベース プロパティが置かれ、ファーム上のすべてのサーバーでスクリプトによるルーティンの実行が容易になります。

この機能により、メリットよりも問題のほうが多くなる場合、この機能を無効にし、IIS 5 スタイルのサイト ID のアルゴリズムに戻すことができます。以下のレジストリ サブキーに IncrementalSiteIDCreation を追加してください。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetMgr\Parameters