WebLogic Server Web コンポーネントのコンフィグレーション

 

以下の節では、WebLogic Server Web コンポーネントをコンフィグレーションする方法について説明します。

• 概要

• HTTP パラメータ

• リスンポートのコンフィグレーション

• Web アプリケーション

• 仮想ホスティングのコンフィグレーション

• WebLogic Server による HTTP リクエストの解決方法

• HTTP アクセス ログの設定

• POST サービス拒否攻撃の防止

• HTTP トンネリングのための WebLogic Server の設定

• 静的ファイルを提供するネイティブ I/O の使用（Windows のみ）

 

---

概要

WebLogic Server は、動的な Java ベース分散アプリケーションのホストとなる他にも、大容量 Web サイトを処理できる高機能 Web サーバとして、HTML ファイルや画像ファイルなどの静的ファイル、およびサーブレットと JavaServer Pages （JSP）を提供します。WebLogic Server は、HTTP 1.1 規格をサポートしています。

 

---

HTTP パラメータ

サーバまたは仮想ホストごとに、Administration Console を使用して HTTP 操作パラメータをコンフィグレーションできます。

属性	説明	指定できる値	デフォルト値
[フロントエンド ホスト]	WebLogic Server は、リクエストをリダイレクトするとき、HTTP 応答ヘッダで返されるホスト名に、[デフォルト サーバ名] で指定されている文字列を設定する。 これは、ファイアウォールまたはロード バランサを使用しているときに、ブラウザからリダイレクトされるリクエストが元のリクエストで送信されたものと同じホスト名を参照するようにしたい場合に便利である。	文字列	null
[フロントエンド HTTP ポート]	ファイアウォールまたはプロキシが存在するために、URL から得られるポート情報が正しくない可能性がある場合は、フロントエンド HTTP ポートを設定する。このパラメータを設定すると、HOST ヘッダーは無視されて、この値が常に使用される。	有効なリスン ポート	null
[フロントエンド HTTPS ポート]	ファイアウォールまたはプロキシが存在するために、URL から得られるポート情報が正しくない可能性がある場合は、フロントエンド HTTPS ポートを設定する。このパラメータを設定すると、HOST ヘッダーは無視されて、この値が常に使用される。	有効なリスン ポート	null
[Keep Alive を有効化]	HTTP キープアライブが有効かどうかを設定する。	ブール True = 有効 False = 無効	True
[ Send Server Header を有効化]	false の場合は、サーバ名が HTTP 応答で送信されない。ヘッダのスペースが限られている無線アプリケーションで便利。	ブール True = 有効 False = 無効	True
[持続時間] （[仮想ホスト] パネルでは [Keep Alive 時間] と表示）	非アクティブな HTTP 接続を閉じるまで WebLogic Server が待機する秒数。	整数	30
[HTTPS 持続時間] （[仮想ホスト] パネルでは [Https Keep Alive 時間] と表示）	非アクティブな HTTPS 接続を閉じるまで WebLogic Server が待機する秒数。	整数	60
[WAP 有効化]	選択すると、セッション ID に JVM 情報が含まれなくなる。これは、URL のサイズを 128 文字に制限する WAP デバイスで URL 書き換えを使用する場合に必要になる。[WAP 有効化] を選択すると、クラスタのレプリケート セッションの使用に影響する場合がある。	有効 無効	無効
[POST タイムアウト秒]	HTTP POST データに含まれる大量のデータを WebLogic Server が受信する際のタイムアウト（単位 : 秒）を設定する。これは、POST データを使用してサーバを過負荷状態にしようとするサービス拒否攻撃を防ぐために使用する。	整数	0
[最大 POST 時間]	HTTP POST データに含まれる大量のデータを WebLogic Server が待ち受ける時間（単位 : 秒）を設定する。	整数	0
[最大 POST サイズ]	HTTP POST データに含まれるデータの最大サイズを設定する。	整数	0
[外部 DNS 名]	クラスタ化した WebLogic Server と Netscape（プロキシ）プラグインなど Web サーバ フロントエンドのプラグインとの間にアドレス変換ファイアウォールを配置したシステムの場合、この属性を、プラグインがこのサーバとの通信に使用するアドレスに設定する。

 

 

---

リスンポートのコンフィグレーション

各 WebLogic Server が HTTP リクエストをリスンするポートを指定できます。任意の有効なポート番号を指定できますが、ポート 80 を指定した場合、HTTP を介してリソースにアクセスするために使用する HTTP リクエストからポート番号を省略できます。たとえば、リスン ポートとしてポート 80 を定義した場合、http://hostname:portnumber/myfile.html ではなく、http://hostname/myfile.html という形式を使用できます。

リスン ポートは、通常のリクエストとセキュアな（SSL を使用した）リクエストで別個に定義します。通常のリスン ポートは Administration Console の サーバ ノードの [コンフィグレーション｜一般] タブで定義し、SSL リスン ポートは [コンフィグレーション｜SSL] タブで定義します。

 

---

Web アプリケーション

HTTP サービスと Web サービスは、Sun Microsystems のサーブレット仕様 2.3 に従ってデプロイされます。この仕様では、Web アプリケーション とは Web ベース アプリケーションのコンポーネントを 1 つにまとめるための標準化された方法であると定義されています。これらのコンポーネントには、JSP ページ、HTTP サーブレット 静的リソース（HTML ページや画像ファイルなど）が含まれます。また Web アプリケーションは、エンタープライズ EJB や JSP タグ ライブラリなどの外部リソースにアクセスすることもできます。各サーバは、任意の数の Web アプリケーションのホストになることができます。通常、Web アプリケーションの名前は、その Web アプリケーションのリソースを要求するために使う URI の一部として使用します。

詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』を参照してください。

Web アプリケーションとクラスタ化

Web アプリケーションは、WebLogic Server のクラスタにデプロイできます。ユーザが Web アプリケーションのリソースを要求すると、そのリクエストはその Web アプリケーションがホストするクラスタの構成サーバの 1 つに転送されます。アプリケーションがセッション オブジェクトを使用する場合、そのセッションはクラスタ内の全サーバにレプリケートされなければなりません。セッションのレプリケートにはいくつかの方法があります。

詳細については、『WebLogic Server Clusters ユーザーズ ガイド』を参照してください。

デフォルト Web アプリケーションの指定

ドメイン内のすべてのサーバおよび仮想ホストで、デフォルト Web アプリケーションを宣言できます。デフォルト Web アプリケーションは、デプロイされている別の Web アプリケーションによって解決できない任意の HTTP リクエストに応答します。他のすべての Web アプリケーションとは異なり、デフォルト Web アプリケーションの名前は、URI の一部として使用されません。サーバまたは仮想ホストに割り当てられた Web アプリケーションを、デフォルト Web アプリケーションとして宣言することができます（Web アプリケーションの割り当てについては、この節で後述します。仮想ホストの詳細については、 仮想ホスティングのコンフィグレーションを参照してください）。

デフォルト ドメイン、および WebLogic Server に付属のサンプル ドメインでは、それぞれデフォルトの Web アプリケーションがすでにコンフィグレーションされています。それらのドメインのデフォルト Web アプリケーションは、DefaultWebApp という名前で各ドメインの applications ディレクトリに配置されています。

正常にデプロイされていないデフォルト Web アプリケーションを宣言すると、エラーがログに記録されるとともに、そのデフォルト Web アプリケーションにアクセスしようとしたユーザに対して HTTP 400 エラー メッセージが表示されます。

たとえば、shopping という Web アプリケーションが存在する場合、その Web アプリケーションの cart.jsp という JSP にアクセスするには、次の URL を使用します。

http://host:port/shopping/cart.jsp

しかし、shopping をデフォルト Web アプリケーションとして指定した場合、cart.jsp にアクセスするには次の URL を使用します。

http://host:port/cart.jsp

（host は WebLogic Server が稼働するマシンのホスト名、port は WebLogic Server がリクエストをリスンするポートの番号）

サーバまたは仮想ホストのデフォルト Web アプリケーションを宣言するには、Administration Consoleを使用して、次の手順を実行します。

1. 左ペインで [Web アプリケーション] ノードを展開します。

2. Web アプリケーションを選択します。

3. 右ペインで、[対象] タブを選択します。

4. [サーバ] タブを選択して、サーバ（または仮想ホスト）を [選択済み] カラムへ移動します。（[クラスタ] タブを選択し、クラスタを [選択済み] カラムへ移動して、クラスタ内の全サーバを割り当てることもできます）。

5. [適用] をクリックします。

6. 左ペインの [サーバ] （または [仮想ホスト]）ノードを展開します。

7. 該当するサーバまたは仮想ホストを選択します。

8. 右ペインの [一般] タブを選択します。

9. [HTTP] タブを選択します。仮想ホストをコンフィグレーションする場合は、代わりに [一般] タブを選択します。

10. [デフォルト Web アプリケーション] ドロップダウン リストから Web アプリケーションを選択します。

11. [適用] をクリックします。

12. 複数の管理対象サーバのデフォルト Web アプリケーションを宣言する場合、各管理対象サーバについてこの手順を繰り返します。

 

---

仮想ホスティングのコンフィグレーション

仮想ホスティングを使用すると、サーバまたはクラスタが応答するホスト名を定義できます。仮想ホスティングを使用するときは、WebLogic Server またはクラスタの IP アドレスにマップする 1 つまたは複数のホスト名を、DNS を使って指定します。また、仮想ホストによって提供される Web アプリケーションを指定します。仮想ホスティングをクラスタ内で使用する場合、ロード バランシング機能により、DNS ホスト名の 1 つが他のホスト名より多くのリクエストを処理する場合でもハードウェアを最も効率的に使用できます。

たとえば、books という Web アプリケーションが仮想ホスト名 www.books.com のリクエストに応答し、これらのリクエストが WebLogic Server A、B、および C に向けられるよう指定し、一方、cars という Web アプリケーションが仮想ホスト名 www.autos.com に応答し、これらのリクエストが WebLogic Server D および E に向けられるよう指定できます。アプリケーションと Web サーバの条件に合わせて、仮想ホスト、WebLogic Server、クラスタ、および Web アプリケーションのさまざまな組み合わせをコンフィグレーションできます。

また、定義した各仮想ホストに対して、個別に HTTP パラメータと HTTP アクセス ログを定義できます。仮想ホストに対して設定された HTTP パラメータとアクセス ログは、サーバ に対して設定された HTTP パラメータとアクセス ログをオーバーライドします。指定できる仮想ホストの数に制限はありません。

仮想ホスティングをアクティブ化するには、仮想ホストをサーバまたはサーバ クラスタに割り当てます。クラスタに割り当てられた仮想ホスティングは、そのクラスタ内のすべてのサーバに適用されます。

仮想ホスティングとデフォルト Web アプリケーション

各仮想ホストに対して、デフォルト Web アプリケーション を指定することもできます。仮想ホストのデフォルト Web アプリケーションは、同じサーバまたはクラスタで仮想ホストとしてデプロイされている別の Web アプリケーションに解決できないすべてのリクエストに応答します。

他の Web アプリケーションとは異なり、デフォルト Web アプリケーションの名前（コンテキスト パスとも言う）は、そのデフォルト Web アプリケーションのリソースにアクセスするために使う URI の一部として使用されません。

たとえば、www.mystore.com という仮想ホスト名を定義し、shopping という Web アプリケーションをデプロイしたサーバにその仮想ホストを割り当てた場合、shopping の cart.jsp という JSP にアクセスするには、次の URI を使用します。

http://www.mystore.com/shopping/cart.jsp

しかし、shopping をこの仮想ホスト www.mystore.com のデフォルト Web アプリケーションとして指定した場合は、次の URI を使用して cart.jsp にアクセスします。

http://www.mystore.com/cart.jsp

詳細については、 WebLogic Server による HTTP リクエストの解決方法を参照してください。

仮想ホストの設定

仮想ホストを定義するには、Administration Console を使用して次の手順を実行します。

1. 仮想ホストを作成します。

   1. 左ペインの [サービス] ノードを展開します。ノードが展開され、サービスのリストが表示されます。

   2. 仮想ホスト ノードをクリックします。仮想ホストが定義されている場合、ノードが展開されて仮想ホストのリストが表示されます。

   3. 右ペインの [新しい Virtual Host のコンフィグレーション] をクリックします。

   4. この仮想ホストを表す名前を入力します。

   5. 仮想ホスト名を 1 行に 1 つずつ入力します。これらの仮想ホスト名に一致するリクエストだけが、この仮想ホストとして指定された WebLogic Server またはクラスタによって処理されます。

   6. （省略可能）この仮想ホストに対して、デフォルト Web アプリケーションを割り当てます。

   7. [作成] をクリックします。

2. ロギングと HTTP パラメータを定義します。

   1. （省略可能）[ログ] タブをクリックし、HTTP アクセス ログ属性を入力します（詳細については、 HTTP アクセス ログの設定を参照）。

   2. [HTTP] タブを選択し、 HTTP パラメータを入力します。

3. この仮想ホストに応答するサーバを定義します。

   1. [対象] タブを選択します。

   2. [サーバ] タブを選択します。使用可能なサーバのリストが表示されます。

   3. [選択可] カラム内のサーバを選択し、右矢印ボタンを使ってサーバを [選択済み] カラムに移動します。

4. この仮想ホストに応答するクラスタを定義します（オプション）。すでに WebLogic Cluster が定義されている必要があります。詳細については、『WebLogic Server Clusters ユーザーズ ガイド』を参照してください。

   1. [対象] タブを選択します。

   2. [クラスタ] タブを選択します。使用可能なサーバのリストが表示されます。

   3. [選択可] カラム内のクラスタを選択し、右矢印ボタンを使ってクラスタを [選択済み] カラムに移動します。仮想ホストは、クラスタ内のすべてのサーバに適用されます。

5. この仮想ホストの対象 Web アプリケーションを選択します。

   1. 左ペインの [Web アプリケーション] ノードをクリックします。

   2. ターゲットにする Web アプリケーションを選択します。

   3. 右ペインの [対象] タブを選択します。

   4. [仮想ホスト] タブを選択します。

   5. [選択可] カラム内の仮想ホストを選択し、右矢印ボタンを使って仮想ホストを [選択済み] カラムに移動します。

なお、仮想ホスト名を指定する行をサーバ上の etc/hosts ファイルに追加して、仮想ホスト名を必ず解決できるようにする必要があります。

 

---

WebLogic Server による HTTP リクエストの解決方法

WebLogic Server が HTTP リクエストを受信すると、WebLogic Server は、URL のさまざまな部分を解析し、その情報を利用してどの Web アプリケーションとサーバがそのリクエストを処理すべきかを決定することによって、そのリクエストを解決します。以下の例では、Web アプリケーション、仮想ホスト、サーブレット、JSP、および静的ファイルのリクエストのさまざまな組み合わせとその応答を示します。

注意: Web アプリケーションをエンタープライズ アプリケーションの一部としてパッケージ化する場合は、Web アプリケーションへのクエストの解決に使用する代わりの名前を指定できます。詳細については、「エンタープライズ アプリケーションの一部としての Web アプリケーションのデプロイメント」を参照してください。

次の表に、WebLogic Server によって提供される URL とファイルのサンプルを示します。「インデックス ディレクトリのチェック」カラムは、特定のファイルが要求されていない場合にディレクトリ リストを提供するかどうかを指定する [インデックス ディレクトリ] 属性に関するものです。[インデックス ディレクトリ] 属性は、Administration Consoleの [Web アプリケーション] ノードの [コンフィグレーション｜ファイル] タブで設定します。

表8-1 WebLogic Server による URL の解決例

URL	インデックス ディレクトリのチェック	応答で提供されるファイル
http://host:port/apples	変更しない	apples Web アプリケーションに定義されているウェルカム ファイル*
http://host:port/apples	変更する	apples Web アプリケーションの最上位ディレクトリのリスト
http://host:port/oranges/naval	関係なし	oranges Web アプリケーション内の /naval という <url-pattern> でマップされているサーブレット サーブレット マッピングでは、いくつか考慮すべきことがある。詳細については、「サーブレットのコンフィグレーション」を参照。
http://host:port/naval	関係なし	oranges Web アプリケーション内の /naval という <urｌ-pattern>にマップされているサーブレットがデフォルト Web アプリケーションとして定義されている。 詳細については、「サーブレットのコンフィグレーション」を参照。
http://host:port/apples/pie.jsp	関係なし	apples Web アプリケーションの最上位ディレクトリにある pie.jsp
http://host:port	変更する	デフォルト Web アプリケーションの最上位ディレクトリのリスト
http://host:port	変更しない	デフォルト Web アプリケーションのウェルカム ファイル*
http://host:port/apples/myfile.html	関係なし	apples Web アプリケーションの最上位ディレクトリにある myfile.html
http://host:port/myfile.html	関係なし	デフォルト Web アプリケーションの最上位ディレクトリにある myfile.html
http://host:port/apples/images/red.gif	関係なし	apples Web アプリケーションの最上位ディレクトリの images サブディレクトリにある red.gif
http://host:port/myFile.html myfile.html が apples Web アプリケーションに存在せず、デフォルト サーブレットが定義されていない場合	関係なし	エラー 404 詳細については、「HTTP エラー応答のカスタマイズ」を参照
http://www.fruit.com/	変更しない	www.fruit.com というホスト名を持つ仮想ホストのデフォルト Web アプリケーションのウェルカム ファイル*
http://www.fruit.com/	変更する	www.fruit.com というホスト名を持つ仮想ホストのデフォルト Web アプリケーションの最上位ディレクトリのリスト
http://www.fruit.com/oranges/myfile.html	関係なし	www.fruit.com というホスト名の仮想ホストに関連付けられている oranges Web アプリケーションの myfile.html

 

* 詳細については、「ウェルカム ページのコンフィグレーション」を参照してください。

 

---

HTTP アクセス ログの設定

WebLogic Server は、HTTP トランザクションのログを、共通ログ フォーマットまたは拡張ログ フォーマットのいずれかのフォーマットでテキスト ファイルに保存します。共通ログ フォーマットは、デフォルトの、標準規則に従った形式です。拡張ログ フォーマットでは、記録されている情報をカスタマイズできます。定義した各サーバまたは各仮想ホストに対して、HTTP アクセス ログの性質を定義する属性を設定できます。

ログ ローテーション

ログ ファイルは、そのファイルのサイズ、または指定した時間のいずれかに基づいてローテーションすることができます。これらの 2 つの条件のいずれかが満たされると、現在のアクセス ログ ファイルが閉鎖され、新しいログ ファイルが開始されます。ログ ローテーションを設定しないと、HTTP アクセス ログ ファイルは無限に大きくなります。アクセス ログ ファイルの名前には、ローテーションごとに増える数値が入ります。HTTP アクセス ログは、定義した Web Server ごとに保存されます。

Administration Consoleを使用した HTTP アクセス ログの設定

HTTP アクセス ログを設定するには、Administration Console を使用して、次の手順を実行します。

1. 仮想ホストを設定してある場合

   1. 左ペインの [サービス] ノードを選択します。

   2. 仮想ホスト ノードを選択します。ノードが展開され、仮想ホストのリストが表示されます。

   3. 仮想ホストを選択します。

      仮想ホストを設定していない場合

   4. 左ペインの [サーバ] ノードを選択します。ノードが展開され、サーバのリストが表示されます。

   5. サーバを選択します。

   6. [ログ] タブを選択します。

   7. [HTTP] タブを選択します。

2. [ログを有効化] ボックスをチェックします。

3. ログ ファイルの名前を入力します。

4. [フォーマット] ドロップダウン リストから [common] または [extended] を選択します。

5. ホスト コンピュータで指定されているローカル タイム ゾーンに関係なく、HTTP ログ メッセージのタイム スタンプをグリニッジ標準時 (GMT) にする場合は、[時間のログ (GMT)] を選択します。

   拡張 (extended) フォーマット ログ ファイルの W3C 仕様に準拠するには、この機能を使用します。この仕様では、拡張フォーマットのログ エントリに対するすべてのタイム スタンプは GMT でなければならないと規定されています。

6. [ログファイル バッファ サイズ] で、HTTP メッセージ バッファのサイズ (キロバイト) を設定します。HTTP メッセージ バッファがこのサイズに達すると、サーバは現在のエントリをすべて HTTP ログ ファイルに書き込み、バッファをフラッシュします。

7. [ローテーション タイプ] で、[サイズ] または [時間] を選択します。

   • [サイズ] : [ログ バッファ サイズ] パラメータに入力した値を超えたときにログをローテーションします。

   • [時間] : [ローテーション間隔] パラメータに指定した分数を超えたときにログをローテーションします。

8. [ローテーション タイプ] で [サイズ] を選択した場合は、サーバがログ メッセージの書き込み先を別のファイルに移動するファイル サイズ (1 〜 65,535 キロバイト) を [最大ログ ファイル サイズ] フィールドで指定します。

   ログ ファイルが指定したサイズに達すると、ファイル サイズが次にチェックされた時点で、現在のログ ファイルの名前が FileName.n に変更され、新しいログ ファイルが作成されて、以降のメッセージは新しいログ ファイルに格納されます。

9. [ローテーション タイプ] で [時間] を選択した場合は、ログ ファイルのローテーションを最初に行う時刻を [ローテーション開始時刻] で設定します。

   hh:mm という形式を使用します。hh は 24 時間形式の時刻で、mm は分です。

   日付と時刻の指定には、MM-dd-yyyy-k:mm:ss という java.text.SimpleDateFormat の形式を使用します。この形式については、『J2EE Javadoc』を参照してください。

   指定した時刻が既に過ぎている場合は、直ちにファイルのローテーションが行われます。

10. [ローテーション タイプ] として [時間] を選択した場合は、[ローテーション間隔] にログ ファイルのローテーション間隔を設定します。

共通ログ フォーマット

HTTP 情報ログのデフォルト フォーマットは、共通ログ フォーマットです。この標準フォーマットのパターンは以下のとおりです。

host RFC931 auth_user [day/month/year:hour:minute:second
    UTC_offset] "request" status bytes

各値の説明は次のとおりです。

host

リモート クライアントの DNS 名または IP 番号。

RFC931

リモート クライアントの IDENTD によって返された情報。WebLogic Server はユーザ識別をサポートしていません。

auth_user

リモート クライアントが認証用にユーザ ID を送信した場合、そのユーザ名。それ以外の場合は 「-」。

day/month/year:hour:minute:second UTC_offset

日、月、年、時間（24 時間形式）、および現地時間と GMT の時差（角括弧で囲まれて示される）。

"request"

リモート クライアントによって送信された HTTP リクエストの最初の行（二重引用符で囲まれて示される）。

status

使用可能な場合、サーバによって返された HTTP ステータス コード。それ以外の場合は「-」。

bytes

既知の場合、HTTP ヘッダのコンテンツ長として示されるバイト数（HTTP ヘッダは含まれない）。それ以外の場合は「-」。

拡張ログ フォーマットを使用した HTTP アクセス ログの設定

WebLogic Server は、W3C によって定義された拡張ログ フォーマット、バージョン 1.0 もサポートしています。このフォーマットは新しく登場した規格で、WebLogic Server は、W3C による草案仕様に準拠しています。最新バージョンは、「W3C Technical Reports and Publications」で参照できます。

拡張ログ フォーマットを使用すると、各 HTTP 通信に関する記録情報のタイプと順序を指定できます。拡張ログ フォーマットを有効にするには、Administration Console の [HTTP] タブで、フォーマットを [extended] に設定します（ ステップ 4.の「Administration Consoleを使用した HTTP アクセス ログの設定」を参照）。

このフォーマットでは、ログ ファイルに記録される情報のタイプをディレクティブによって指定します。ディレクティブは、実際のログ ファイルに組み込まれます。ディレクティブは、新しい行から「#」という記号で始まります。ログファイルが存在しない場合、デフォルト ディレクティブが記述された新しいログ ファイルが作成されます。しかし、サーバの起動時にログ ファイルがすでに存在する場合、そのファイルの先頭には有効なディレクティブが存在しなければなりません。

Fields ディレクティブの作成

ログ ファイルの最初の行には、そのログ ファイル フォーマットのバージョン番号を示すディレクティブが存在しなければなりません。また、ファイルの先頭の近くには、Fields ディレクティブが存在しなければなりません。

  #Version: 1.0
  #Fields: xxxx xxxx xxxx ...

ここで各 xxxx は、記録されるデータ フィールドを表します。フィールド タイプは、W3C 仕様に定義されているとおり、単純な識別子として指定されるか、またはプレフィックス-識別子というフォーマットを取ります。次に例を示します。

  #Fields:date time cs-method cs-uri

この識別子は、HTTP アクセスごとにトランザクションの日付と時間、クライアントが使用したリクエスト メソッド、およびリクエストの URI を記録するようサーバに指示します。各フィールドはスペースによって区切られ、各レコードは新しい行に書き込まれてログ ファイルに追加されます。

注意 : ログ ファイル内の#Fields ディレクティブの後には新しい行が続かなければなりません。これは、最初のログ メッセージがディレクティブと同じ行に追加されないようにするためです。

サポートされるフィールド識別子

以下の識別子がサポートされています。プレフィックスは必要ありません。

date

トランザクションが完了した日付。W3C 仕様で定義されているフィールド タイプは <date>

time

トランザクションが完了した時間。 W3C 仕様で定義されているフィールド タイプは <time>

time-taken

トランザクションが完了するまでの時間。 W3C 仕様で定義されているフィールド タイプは <fixed>

bytes

転送されたバイト数。フィールド タイプは <integer>

W3C 仕様で定義されている cached フィールドは、WebLogic Server ではサポートされていません。

以下の識別子はプレフィックスを必要とし、単独では使用できません。ここでは、サポートされている個々のプレフィックスの組み合わせについて説明します。

IP アドレス関連フィールド

これらのフィールドには、リクエストを行ったクライアントまたは応答したサーバのいずれかの IP アドレスとポートが記録されます。W3C 仕様で定義されているフィールド タイプは <address> です。サポートされるプレフィックスは以下のとおりです。

c-ip

クライアントの IP アドレス

s-ip

サーバの IP アドレス

DNS 関連フィールド

これらのフィールドには、クライアントまたはサーバのドメイン名が記録されます。W3C 仕様で定義されているフィールド タイプは <name> です。サポートされるプレフィックスは以下のとおりです。

c-dns

リクエストを送信したクライアントのドメイン名

s-dns

リクエストを受信したサーバのドメイン名

sc-status

応答のステータス コード。たとえば、(404) は「File not found」というステータスを表します。W3C 仕様で定義されているフィールド タイプは <integer> です。

sc-comment

ステータス コードと一緒に返されるコメント（「File not found」など）。このフィールド タイプは <text> です。

cs-method

リクエスト メソッド（GET や POST など）。W3C 仕様で定義されているフィールド タイプは <name> です。

cs-uri

完全なリクエスト URI。W3C 仕様で定義されているフィールド タイプは <uri> です。

cs-uri-stem

URI の基本部分のみ（クエリを省略）。W3C 仕様で定義されているフィールド タイプは <uri> です。

cs-uri-query

URI のクエリ部分のみ。W3C 仕様で定義されているフィールド タイプは <uri> です。

カスタム フィールド識別子の作成

拡張ログ フォーマットを使用する HTTP アクセス ログ ファイルに追加するために、ユーザ定義のフィールドを作成することもできます。カスタム フィールドを作成するには、ELF ログ ファイルで Fields ディレクティブを使用してフィールドを指定します。次に、そのフィールドに対応し、必要な出力が生成される Java クラスを作成します。フィールドごとに別々の Java クラスを作成することも、複数のフィールドを出力する Java クラスを作成することもできます。このようなクラスの Java ソースのサンプルをこのマニュアルの中で示します。 カスタム ELF フィールドを作成する Java クラスを参照してください。

カスタム フィールドを作成するには、次の手順に従います。

1. 次の形式を使用して、Fields ディレクティブにフィールド名を追加します。

   x-myCustomField.

   myCustomField は完全修飾クラス名です。

   Fields ディレクティブの詳細については、 Fields ディレクティブの作成を参照してください。

2. Fields ディレクティブで定義したカスタム フィールド（myCustomField など）と同じ完全修飾クラス名を持つ Java クラスを作成します。このクラスではカスタム フィールドにロギングする情報を定義します。Java クラスには次のインタフェースを実装する必要があります。

   weblogic.servlet.logging.CustomELFLogger

   Java クラスでは、logField() メソッドを実装しなければなりません。このメソッドは、HttpAccountingInfo オブジェクトと FormatStringBuffer オブジェクトを引数として取ります。

   • HttpAccountingInfo オブジェクトを使用して、HTTP リクエストとカスタム フィールドに出力できる応答データにアクセスします。この情報にアクセスするためのゲッター メソッドが提供されています。get メソッドの完全なリストについては、 HttpAccountingInfo オブジェクトの get メソッドを参照してください。

   • FormatStringBuffer クラスを使用して、カスタム フィールドのコンテンツを作成します。適切な出力を作成するためのメソッドが提供されています。このメソッドの詳細については、FormatStringBuffer の Javadoc を参照してください。

3. Java クラスをコンパイルして、WebLogic Server の起動に使用される CLASSPATH 文にクラスを追加します。WebLogic Server の起動に使用するスクリプト内の CLASSPATH 文を変更する必要があります。

   注意: このクラスを、展開形式または jar 形式で、Web アプリケーションまたはエンタープライズ アプリケーションの内部に配置しないでください。

4. 拡張ログ フォーマットを使用するように WebLogic Server をコンフィグレーションします。詳細については、 拡張ログ フォーマットを使用した HTTP アクセス ログの設定を参照してください。

注意: カスタム フィールドを定義する Java クラスの記述では、システムの処理速度を低下させるようなコードは実行しないでください（たとえば、DBMS へのアクセス、大量の I/O、または ネットワークの呼び出しなど）。HTTP アクセス ログ ファイルのエントリは HTTP リクエストごとに作成されます。

注意: 複数のフィールドを出力する場合は、タブでフィールドを区切ります。フィールドの区切り方およびその他の ELF フォーマットの詳細については、「Extended Log Format」を参照してください。

HttpAccountingInfo オブジェクトの get メソッド

次のメソッドは HTTP リクエストに関するさまざまなデータを返します。これらのメソッドは、javax.servlet.ServletRequest、javax.servlet.http.Http.ServletRequest、および javax.servlet.http.HttpServletResponse のさまざまなメソッドと似ています。

これらのメソッドの詳細については、次の表に示す Java インタフェースの対応するメソッドを参照するか、表内の特定の情報を参照してください。

表8-2 HttpAccountingInfo のゲッター メソッド

HttpAccountingInfo のメソッド	メソッドに関する情報の参照先
Object getAttribute(String name);	javax.servlet.ServletRequest
Enumeration getAttributeNames();	javax.servlet.ServletRequest
String getCharacterEncoding();	javax.servlet.ServletRequest
int getResponseContentLength();	javax.servlet.ServletResponse. setContentLength() このメソッドは応答のコンテンツ長を取得し、setContentLength() メソッドと共に設定する。
String getContentType();	javax.servlet.ServletRequest
Locale getLocale();	javax.servlet.ServletRequest
Enumeration getLocales();	javax.servlet.ServletRequest
String getParameter(String name);	javax.servlet.ServletRequest
Enumeration getParameterNames();	javax.servlet.ServletRequest
String[] getParameterValues(String name);	javax.servlet.ServletRequest
String getProtocol();	javax.servlet.ServletRequest
String getRemoteAddr();	javax.servlet.ServletRequest
String getRemoteHost();	javax.servlet.ServletRequest
String getScheme();	javax.servlet.ServletRequest
String getServerName();	javax.servlet.ServletRequest
int getServerPort();	javax.servlet.ServletRequest
boolean isSecure();	javax.servlet.ServletRequest
String getAuthType();	javax.servlet.http.Http.ServletRequest
String getContextPath();	javax.servlet.http.Http.ServletRequest
Cookie[] getCookies();	javax.servlet.http.Http.ServletRequest
long getDateHeader(String name);	javax.servlet.http.Http.ServletRequest
String getHeader(String name);	javax.servlet.http.Http.ServletRequest
Enumeration getHeaderNames();	javax.servlet.http.Http.ServletRequest
Enumeration getHeaders(String name);	javax.servlet.http.Http.ServletRequest
int getIntHeader(String name);	javax.servlet.http.Http.ServletRequest
String getMethod();	javax.servlet.http.Http.ServletRequest
String getPathInfo();	javax.servlet.http.Http.ServletRequest
String getPathTranslated();	javax.servlet.http.Http.ServletRequest
String getQueryString();	javax.servlet.http.Http.ServletRequest
String getRemoteUser();	javax.servlet.http.Http.ServletRequest
String getRequestURI();	javax.servlet.http.Http.ServletRequest
String getRequestedSessionId();	javax.servlet.http.Http.ServletRequest
String getServletPath();	javax.servlet.http.Http.ServletRequest
Principal getUserPrincipal();	javax.servlet.http.Http.ServletRequest
boolean isRequestedSessionIdFromCookie();	javax.servlet.http.Http.ServletRequest
boolean isRequestedSessionIdFromURL();	javax.servlet.http.Http.ServletRequest
boolean isRequestedSessionIdFromUrl();	javax.servlet.http.Http.ServletRequest
boolean isRequestedSessionIdValid();	javax.servlet.http.Http.ServletRequest
String getFirstLine();	HTTP リクエストの最初の行を返す。 例 : GET /index.html HTTP/1.0
long getInvokeTime();	サーブレットのサービス メソッドがデータをクライアントへ書き戻すのにかかる時間を返す。
int getResponseStatusCode();	javax.servlet.http.HttpServletResponse
String getResponseHeader(String name);	javax.servlet.http.HttpServletResponse

コード リスト 8-1 カスタム ELF フィールドを作成する Java クラス

import weblogic.servlet.logging.CustomELFLogger;
import weblogic.servlet.logging.FormatStringBuffer;
import weblogic.servlet.logging.HttpAccountingInfo;

/* この例では、User-Agent フィールドを
   MyCustomField というカスタム フィールドに出力する
*/

public class MyCustomField implements CustomELFLogger{

public void logField(HttpAccountingInfo metrics,
  FormatStringBuffer buff) {
  buff.appendValueOrDash(metrics.getHeader("User-Agent"));
  }
}

 

---

POST サービス拒否攻撃の防止

サービス拒否攻撃とは、偽りのリクエストによってサーバを過負荷状態にしようとする悪意ある試みです。一般的な攻撃の 1 つは、HTTP POST メソッドで膨大な量のデータを送信するというものです。WebLogic Server では、3 つの属性を設定して、この種の攻撃を防くことができます。3 つの属性は、コンソールの [サーバ] または [仮想ホスト] で設定します。これらの属性を仮想ホストに対して設定した場合、その値は [サーバ] で設定した値をオーバーライドします。

[Post タイムアウト秒]

HTTP POST に含まれる大量のデータを WebLogic Server が受信する間隔を制限できます。

[最大 Post 時間]

WebLogic Server が POST データを受信するために費やす総時間数を制限します。この制限を超えた場合、PostTimeoutException が送出され、次のメッセージがサーバ ログに記録されます。

Post time exceeded MaxPostTimeSecs.

MaxPostSize

単一の POST リクエストで受領するデータのバイト数を制限します。この制限を超えた場合、MaxPostSizeExceeded が送出され、次のメッセージがサーバ ログに記録されます。

POST size exceeded the parameter MaxPostSize.

HTTP エラー コード 413 （Request Entity Too Large）がクライアントに返されます。

クライアントがリスン モードの場合、クライアントはこれらのメッセージを取得します。クライアントがリスン モードでない場合は、接続は切断されます。

 

---

HTTP トンネリングのための WebLogic Server の設定

HTTP トンネリングとは、HTTP プロトコルしか使用できないときに、WebLogic Server と Java クライアントの間にステートフルなソケット接続をシミュレートするための手段です。HTTP トンネリングは、通常セキュリティ ファイアウォール内の HTTP ポートを「トンネリング」するために使用されます。HTTP はステートレスなプロトコルですが、WebLogic Server はトンネリング機能を提供して接続を通常の T3Connection のように見せかけます。しかし、通常のソケット接続に比べてパフォーマンスが若干低下する場合があります。

HTTP トンネリング接続の設定

HTTP プロトコルでは、クライアントはリクエストを送信し、サーバから応答を受信することしかできません。一方、サーバも自主的にクライアントと通信できません。つまり、HTTP プロトコルはステートレスであり、連続的な双方向接続を行うことができません。

WebLogic HTTP トンネリングは、HTTP プロトコルを通して T3Connection をシミュレートすることによって、こうした制限を乗り越えます。トンネリング接続を調整してパフォーマンスを向上させるには、Administration Console で 2 つの属性を設定します。これらの属性にアクセスするには、[サーバ] の [コンフィグレーション｜チューニング] タブを開きます。接続に関する問題が発生しない限り、これらの属性はデフォルトのままにしておくことをお勧めします。これらの属性は、クライアント接続が有効かどうか、またはクライアントが生存しているかどうかをサーバが調べるために使用されます。

[トンネリングを有効化]

HTTP トンネリングを有効または無効にします。HTTP トンネリングはデフォルトでは無効です。

[トンネリング クライアント Ping]

HTTP トンネリング接続が設定されると、クライアントは自動的にリクエストをサーバに送信し、サーバは自主的にクライアントに応答できるようになります。また、クライアントはリクエストに指示を入れることができますが、この処理はクライアント アプリケーションがサーバと通信する必要があるかどうかに関係なく発生します。この属性で設定された秒数以内にサーバがクライアントのリクエストに（アプリケーション コードの一部として）応答しない場合、クライアントはその処理を行います。クライアントは応答を受信し、自動的に別のリクエストを即座に送信します。

デフォルトは 45 秒で、有効な範囲は 20 〜 900 秒です。

[トンネリング クライアント タイムアウト]

クライアントがサーバーに対して（応答に対する）リクエストを最後に送信してから、この属性で設定された秒 数が経過した場合、サーバはクライアントを応答なしと見なしてHTTP トンネル接続を終了します。サーバはこの属性によって指定された間隔で経過時間をチェックし、それまでにクライアントからリクエストがあればそれに応答します。

デフォルトは 40 秒で、有効な範囲は 10 〜 900 秒です。

クライアントからの WebLogic Server への接続

クライアントが WebLogic Server への接続を要求する場合、HTTP トンネリングを使用するために必要なことは URL に HTTP プロトコルを指定することだけです。次に例を示します。

  Hashtable env = new Hashtable();
  env.put(Context.PROVIDER_URL, "http://wlhost:80");
  Context ctx = new InitialContext(env);

クライアント側では、特殊なタグが http プロトコルに付加されます。このため WebLogic Server は、これが通常の HTTP リクエストではなくトンネリング接続であることを認識します。この処理では、アプリケーション コードを変更する必要はありません。

クライアントは、ポートが 80 の場合でも URL にポートを指定しなければなりません。WebLogic Server では HTTP リクエスト用のリスン ポートを任意に設定できますが、ポート 80 を使用するのが最も一般的です。通常、ファイアウォールを介したポート 80 へのリクエストは許可されるからです。

WebLogic Server 用のリスン ポートは、Administration Consoleの [サーバ] ノードの [コンフィグレーション｜一般] タブで指定します。

 

---

静的ファイルを提供するネイティブ I/O の使用（Windows のみ）

Windows NT/2000 上で WebLogic Server を実行する場合、WebLogic Server で Java メソッドを使用する代わりにネイティブ オペレーティング システム呼び出しの TramsmitFile を使用するように指定して、HTML ファイル、テキスト ファイル、および画像ファイルなどの静的ファイルを提供することができます。ネイティブ I/O を使用すると、サイズの大きな静的ファイルを提供するときのパフォーマンスが向上します。

ネイティブ I/O を使用するには、ネイティブ I/O を使用して提供するファイルが含まれている Web アプリケーションの web.xml デプロイメント記述子に 2 つのパラメータを追加します。1 つ目のパラメータ、weblogic.http.nativeIOEnabled を TRUE に設定して、ネイティブ I/O ファイルの提供を有効にします。2 つ目のパラメータ、weblogic.http.minimumNativeFileSize にはネイティブ I/O を使用するファイルの最小サイズを設定します。提供するファイルがこの値より大きい場合にネイティブ I/O が使用されます。このパラメータを指定しない場合、400 バイトの値が使用されます。

通常、ネイティブ I/O では、提供するファイルが大きいほどパフォーマンスが向上します。ただし、WebLogic Server を実行するマシンの負荷が増大すると、この利点は小さくなります。weblogic.http.minimumNativeFileSize の適切な値を見つけるためにテストする必要があります。

以下の例では、web.xml デプロイメント記述子に追加するすべてのエントリを示します。このエントリは、web.xml ファイルで、<distributable> 要素の後、<servlet> 要素の前に配置しなければなりません。

<context-param>
　<param-name>weblogic.http.nativeIOEnabled</param-name>
　<param-value>TRUE</param-value>
</context-param>

<context-param>
　<param-name>weblogic.http.minimumNativeFileSize</param-name>
　<param-value>500</param-value>
</context-param>

デプロイメント記述子の記述の詳細については、「Web プリケーションのデプロイメント記述子の記述」を参照してください。