| Oracle® Fusion Middleware Oracle WebLogic Serverサーバー環境の構成 11gリリース1 (10.3.6) B60987-05 |
|
 前 |
 次 |
次の項では、WebLogic ServerでホストされるJava EE Webアプリケーションを、静的コンテンツをホストする標準HTTP Webサーバーとして機能するように構成する方法を説明します。Webアプリケーションでは、JSPおよびサーブレットなどの動的コンテンツもホストできます。詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』を参照してください。
WebLogic Serverは、動的なJavaベース分散アプリケーションをホストする他にも、大容量Webサイトを処理する高機能Webサーバーとして、HTMLファイルや画像ファイルなどの静的ファイル、およびサーブレットとJavaServer Pages (JSP)を提供します。WebLogic Serverでは、HTTP 1.1規格をサポートしています。
各WebLogic ServerがHTTPリクエストをリスニングするポートを指定できます。任意の有効なポート番号を指定できますが、ポート80を指定した場合、HTTPを介してリソースにアクセスするために使用するHTTPリクエストからポート番号を省略できます。たとえば、リスニング・ポートとしてポート80を定義した場合、http://hostname:portnumber/myfile.htmlではなく、http://hostname/myfile.htmlという形式を使用できます。
UNIXシステムでは、プロセスを1025より小さいポートにバインドする場合は、権限があるユーザー(通常はroot)で行う必要があります。したがって、WebLogic Serverがポート80をリスニングするようにするには、権限があるユーザーとしてWebLogic Serverを起動しなければなりません。しかし、セキュリティの観点からすると、WebLogic Serverのように長時間にわたって実行するプロセスを、必要以上の権限で実行するのは望ましくありません。WebLogic Serverにroot権限が必要なのは、ポートがバインドされるまでです。
weblogic.system.enableSetUIDプロパティを(必要に応じてweblogic.system.enableSetGIDプロパティも)trueに設定することで、WebLogic Serverがポート80にバインドした後にUNIXユーザーID (UID)を切り替えるための内部プロセスを有効にできます。これらに対応するweblogic.system.nonPrivUserプロパティとweblogic.system.nonPrivGroupプロパティは、WebLogic Serverの起動後の実行に使用する権限のないUNIXユーザー・アカウント(必要に応じてグループ名)を識別します。
|
注意: UNIXマシンで実行されているノード・マネージャを使用して管理サーバーを起動する際、次のJavaシステム・プロパティを使用すると、これらのオプションを設定できます。 |
UNIXアカウントは、ほとんどのUNIXシステムで権限が最も低い「nobody」に切り替えることができます。必要な場合は、WebLogic Serverの実行専用のUNIXユーザー・アカウントを作成します。権限のないユーザーは、WebLogic Serverで必要になるファイル(ログ・ファイル、WebLogicクラスなど)にアクセスできるように設定してください。WebLogicプロセスの所有権が権限のないユーザーに切り替わると、WebLogicの読み込み、書き込み、および実行の許可がそのユーザーと同じになります。
リスニング・ポートは、非SSLのリクエストとセキュアな(SSLを使用した)リクエストで別個に定義します。リスニング・ポートの構成の詳細は、「ネットワーク・チャネルについて」を参照してください。
管理コンソールを使用して、リスニング・ポートにポート80を設定します。「リスニング・ポートの構成」を参照してください。
WebLogic ServerをホストしているマシンでWindowsが動作している場合、ステップ8へ進みます。
管理コンソールを使用して新しいUNIXマシンを作成します。「マシンの作成と構成」を参照してください。
「バインド後のユーザーIDを有効化」フィールドを選択します。
「バインド後のユーザーID」フィールドに、WebLogic Serverを実行するユーザーの名前を入力します。
「バインド後のグループIDを有効化」フィールドを選択します。
「バインド後のグループIDを有効化」フィールドに、WebLogic Serverを実行するグループの名前を入力します。
「Save」をクリックします。
管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
HTTPアプリケーションとWebアプリケーションは、サーブレット仕様2.4およびJSP仕様2.0に従ってデプロイされます。これらの仕様では、WebアプリケーションがWebベース・アプリケーションのコンポーネントをグループ化するための標準として定義されています。これらのコンポーネントには、JSPページ、HTTPサーブレット静的リソース(HTMLページや画像ファイルなど)が含まれます。またWebアプリケーションは、エンタープライズEJBやJSPタグ・ライブラリなどの外部リソースにアクセスすることもできます。各サーバーは、任意の数のWebアプリケーションのホストになることができます。通常、Webアプリケーションの名前は、そのWebアプリケーションからリソースをリクエストするために使用するURIの一部として使用します。
詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』を参照してください。
Webアプリケーションは、WebLogic Serverクラスタにデプロイできます。ユーザーがWebアプリケーションのリソースをリクエストすると、そのリクエストはそのWebアプリケーションがホストするクラスタ内のサーバーの1つに転送されます。アプリケーションがセッション・オブジェクトを使用する場合、そのセッションはクラスタ内の全ノードにレプリケートする必要があります。セッションのレプリケートにはいくつかの方法があります。
詳細は、『Oracle WebLogic Serverクラスタの使用』を参照してください。
仮想ホスティングを使用すると、サーバーまたはクラスタが応答するホスト名を定義できます。仮想ホスティングを使用するときは、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アプリケーションのリソースにアクセスするために使う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リクエストの解決方法」を参照してください。
複数の仮想ホストを別々のデフォルトWebアプリケーションで使用する場合は、シングル・サインオンは使用できません。それぞれのWebアプリケーションが、以前のWebアプリケーションに設定されたJSESSIONID Cookieを上書きしてしまうためです。これは、すべてのデフォルトWebアプリケーションでCookieName、CookiePath、およびCookieDomainをまったく同じにしても発生します。
仮想ホストを定義するには、管理コンソールを使用して次の手順を実行します。「仮想ホスト」を参照してください。
仮想ホスト名を確実に解決できるように、サーバー上のetc/hostsファイルに仮想ホストのネーミングの行を追加します。
WebLogic ServerがHTTPリクエストを受信すると、WebLogic Serverは、URLの様々な部分を解析し、その情報を利用してどのWebアプリケーションとサーバーがそのリクエストを処理すべきかを決定することによって、そのリクエストを解決します。表5-1では、Webアプリケーション、仮想ホスト、サーブレット、JSP、および静的ファイルのリクエストの様々な組み合わせとそのレスポンスを示します。
|
注意: Webアプリケーションをエンタープライズ・アプリケーションの一部としてパッケージ化する場合は、Webアプリケーションへのリクエストの解決に使用するために、Webアプリケーションに別の名前を指定できます。詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』を参照してください。 |
表5-1に、WebLogic Serverによって提供されるURLとファイルのサンプルを示します。「索引ディレクトリはチェックされているか」の列は、特定のファイルがリクエストされなかった場合にディレクトリ・リストを提供するかどうかを制御する索引ディレクトリ属性の設定を示します。
表5-1 WebLogic ServerによるURLの解決例
| URL | 索引ディレクトリはチェックされているか | レスポンスで提供されるファイル |
|---|---|---|
http://host:port/apples |
いいえ |
|
http://host:port/apples |
はい |
|
http://host:port/oranges/naval |
どちらでもよい |
サーブレット・マッピングには、いくつかの考慮事項があります。詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のサーブレットの構成に関する項を参照してください。 |
http://host:port/naval |
どちらでもよい |
詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のサーブレットの構成に関する項を参照してください。 |
http://host:port/apples/pie.jsp |
どちらでもよい |
|
http://host:port |
はい |
デフォルトWebアプリケーションの最上位レベルのディレクトリのリスト |
http://host:port |
いいえ |
デフォルトWebアプリケーションのウェルカム・ファイル* |
http://host:port/apples/myfile.html |
どちらでもよい |
|
http://host:port/myfile.html |
どちらでもよい |
デフォルトWebアプリケーションの最上位レベルのディレクトリにある |
http://host:port/apples/images/red.gif |
どちらでもよい |
|
http://host:port/myFile.html
|
どちらでもよい |
エラー404 |
http://www.fruit.com/ |
いいえ |
|
http://www.fruit.com/ |
はい |
|
http://www.fruit.com/oranges/myfile.html |
どちらでもよい |
|
WebLogic Serverは、HTTPトランザクションのログを、共通ログ・フォーマットまたは拡張ログ・フォーマットのいずれかのフォーマットでテキスト・ファイルに保存します。デフォルトは共通ログ・フォーマットです。拡張ログ・フォーマットでは、記録されている情報をカスタマイズできます。定義した各サーバー・インスタンスまたは各仮想ホストに対して、HTTPアクセス・ログの動作を定義する属性を設定できます。
サーバーまたは仮想ホストに対するHTTPログを設定するには、Oracle WebLogic Server管理コンソール・ヘルプの次のトピックを参照してください。
ログ・ファイルは、そのファイルのサイズ、または指定した時間のいずれかに基づいてローテーションさせることができます。どちらかの条件が満たされると、現在のアクセス・ログ・ファイルが閉鎖され、新しいログ・ファイルが開始されます。ログ・ローテーションを設定しないと、HTTPアクセス・ログ・ファイルは無限に大きくなります。アクセス・ログ・ファイルの名前は、いつファイルがローテーションされたのかを示す日付と時刻のスタンプが含まれるように構成できます。タイムスタンプを構成しない場合、ローテーションされた各ファイルの名前にはローテーションごとにインクリメントされる数値が含まれます。HTTPアクセス・ログは、定義した仮想ホストごとに保存されます。
ログに記録されるHTTP情報のデフォルトのフォーマットは、共通ログ・フォーマットです(http://www.w3.org/Daemon/User/Config/Logging.html#common-logfile-formatを参照)。この標準フォーマットのパターンは以下のとおりです。
host RFC931 auth_user [day/month/year:hour:minute:second
UTC_offset] "request" status bytes
説明:
リモート・クライアントのDNS名またはIP番号。
リモート・クライアントのIDENTDによって戻された情報。WebLogic Serverでは、ユーザー識別はサポート対象外。
リモート・クライアントのユーザーが認証用にユーザーIDを送信した場合、そのユーザー名。それ以外の場合は「-」。
日、月、年、時間(24時間形式)、および現地時間とGMTの時差(大カッコで囲まれて示されます)。
リモート・クライアントによって送信されたHTTPリクエストの最初の行(二重引用符で囲まれて示されます)。
使用可能な場合、サーバーによって戻されたHTTPステータス・コード。それ以外の場合は「-」。
既知の場合、HTTPヘッダーでコンテンツ長として示されるバイト数(HTTPヘッダーは含まない)。それ以外の場合は「-」
WebLogic Serverは、拡張ログ・ファイル・フォーマットのバージョン1.0もサポートしています。これはW3C (http://www.w3.org/TR/WD-logfile.html)の仕様草案で定義された新しく拡大しつつある標準です。この件について現在、最も信頼性のある参照先は「W3C Technical Reports and Publications」ページ(http://www.w3.org/TR/)です。
拡張ログ・フォーマットを使用すると、各HTTP通信に関する記録情報のタイプと順序を指定できます。このフォーマットを有効にするには、管理コンソールの「HTTP」タブで、「フォーマット」属性をExtendedに設定します。(「カスタム・フィールド識別子の作成」を参照してください。)
このフォーマットでは、ログ・ファイルに記録される情報のタイプをディレクティブによって指定します。ディレクティブは、実際のログ・ファイルに組み込まれます。ディレクティブは、新しい行から「#」という記号で始まります。ログファイルが存在しない場合、デフォルト・ディレクティブが記述された新しいログ・ファイルが作成されます。しかし、サーバーの起動時にログ・ファイルがすでに存在する場合、そのファイルの先頭には有効なディレクティブが存在しなければなりません。
ログ・ファイルの最初の行には、そのログ・ファイル・フォーマットのバージョン番号を示すディレクティブが存在しなければなりません。また、ファイルの先頭の近くには、Fieldsディレクティブが存在しなければなりません。
#Version: 1.0 #Fields: xxxx xxxx xxxx ...
ここで各xxxxは、記録されるデータ・フィールドを表します。フィールド・タイプは、W3C仕様に定義されているとおり、単純な識別子として指定されるか、または接頭辞-識別子というフォーマットを取ります。たとえば:
#Fields: date time cs-method cs-uri
この識別子は、HTTPアクセスごとにトランザクションの日付と時間、クライアントが使用したリクエスト・メソッド、およびリクエストのURIを記録するようサーバーに指示します。各フィールドはスペースによって区切られ、各レコードは新しい行に書き込まれてログ・ファイルに追加されます。
|
注意: ログ・ファイル内の |
以下の識別子がサポートされています。接頭辞は必要ありません。
トランザクションが完了した日付。W3C仕様で定義されているフィールド・タイプは<date>。
トランザクションが完了した時間。W3C仕様で定義されているフィールド・タイプは<time>。
トランザクションが完了するまでの時間。W3C仕様で定義されているフィールド・タイプは<fixed>。
転送されたバイト数。フィールド・タイプは<integer>。
W3C仕様で定義されているcachedフィールドは、WebLogic Serverではサポートされていません。
以下の識別子は接頭辞を必要とし、単独では使用できません。ここでは、サポートされている個々の接頭辞の組み合わせについて説明します。
これらのフィールドには、リクエストを行ったクライアントまたは応答したサーバーのいずれかのIPアドレスとポートが記録されます。W3C仕様で定義されているフィールド・タイプは<address>です。サポートされる接頭辞は以下のとおりです。
クライアントのIPアドレス。
サーバーのIPアドレス。
これらのフィールドには、クライアントまたはサーバーのドメイン名が記録されます。W3C仕様で定義されているフィールド・タイプは<name>です。サポートされる接頭辞は以下のとおりです。
リクエストを送信したクライアントのドメイン名。
リクエストを受信したサーバーのドメイン名。
レスポンスのステータス・コード。たとえば、(404)は「File not found」というステータスを表します。W3C仕様で定義されているフィールド・タイプは<integer>です。
ステータス・コードと一緒に戻されるコメント(「File not found」など)。このフィールド・タイプは<text>です。
リクエスト・メソッド(GETやPOSTなど)。W3C仕様で定義されているフィールド・タイプは<name>です。
完全なリクエストURI。W3C仕様で定義されているフィールド・タイプは<uri>です。
URIの基本部分のみ(問合せを省略)。W3C仕様で定義されているフィールド・タイプは<uri>です。
URIの問合せ部分のみ。W3C仕様で定義されているフィールド・タイプは<uri>です。
拡張ログ・フォーマット(ELF)を使用するHTTPアクセス・ログ・ファイルに追加するために、ユーザー定義のフィールドを作成することもできます。カスタム・フィールドを作成するには、ELFログ・ファイルでFieldsディレクティブを使用してフィールドを指定します。次に、そのフィールドに対応し、必要な出力が生成されるJavaクラスを作成します。フィールドごとに別々のJavaクラスを作成することも、複数のフィールドを出力するJavaクラスを作成することもできます。このようなクラスのJavaソースの例については、「カスタムELFフィールドを作成するJavaクラス」を参照してください。
カスタム・フィールドを作成するには:
次の形式を使用して、Fieldsディレクティブにフィールド名を追加します。
x-myCustomField.
myCustomFieldは完全修飾クラス名です。
Fieldsディレクティブの詳細は、「Fieldsディレクティブの作成」を参照してください。
Fieldsディレクティブで定義したカスタム・フィールド(myCustomFieldなど)と同じ完全修飾クラス名を持つJavaクラスを作成します。このクラスではカスタム・フィールドにロギングする情報を定義します。Javaクラスには次のインタフェースを実装する必要があります。
weblogic.servlet.logging.CustomELFLogger
Javaクラスでは、logField()メソッドを実装しなければなりません。このメソッドは、HttpAccountingInfoオブジェクトとFormatStringBufferオブジェクトを引数として取ります。
HttpAccountingInfoオブジェクトを使用して、HTTPリクエストとカスタム・フィールドに出力できるレスポンス・データにアクセスします。この情報にアクセスするためのゲッター・メソッドが提供されています。getメソッドの完全なリストについては、「HttpAccountingInfoオブジェクトのgetメソッド」を参照してください。
FormatStringBufferクラスを使用して、カスタム・フィールドのコンテンツを作成します。適切な出力を作成するためのメソッドが提供されています。
Javaクラスをコンパイルして、WebLogic Serverの起動に使用されるCLASSPATH文にクラスを追加します。WebLogic Serverの起動に使用するスクリプト内のCLASSPATH文を変更する必要があります。
|
注意: このクラスを、展開形式またはjar形式で、Webアプリケーションまたはエンタープライズ・アプリケーションの内部に配置しないでください。 |
拡張ログ・フォーマットを使用するようにWebLogic Serverを構成します。詳細は、「拡張ログ・フォーマットを使用したHTTPアクセス・ログの設定」を参照してください。
|
注意: カスタム・フィールドを定義するJavaクラスの記述では、システムの処理速度を低下させるようなコードは実行しないでください(たとえば、DBMSへのアクセス、大量のI/O、またはネットワークの呼び出しなど)。HTTPアクセス・ログ・ファイルのエントリはHTTPリクエストごとに作成されます。 |
|
注意: 複数のフィールドを出力する場合は、タブでフィールドを区切ります。複数のフィールドを区切る方法や、その他のELFフォーマット問題の詳細は、 |
次のメソッドはHTTPリクエストに関する様々なデータを戻します。これらのメソッドは、javax.servlet.ServletRequest、javax.servlet.http.Http.ServletRequest、およびjavax.servlet.http.HttpServletResponseの様々なメソッドと似ています。
こうしたインタフェースについてのJavadocは、以下のURLで参照できます。
http://download.oracle.com/javaee/5/api/javax/servlet/ServletRequest.html
http://download.oracle.com/javaee/5/api/javax/servlet/ServletResponse.html
http://download.oracle.com/javaee/5/api/javax/servlet/http/HttpServletRequest.html
これらのメソッドの詳細については、次の表に示すJavaインタフェースの対応するメソッドを参照するか、表内の特定の情報を参照してください。
表5-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() このメソッドはレスポンスのコンテンツ長を取得し、 |
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.HttpServletRequest |
String getContextPath(); |
javax.servlet.http.HttpServletRequest |
Cookie[] getCookies(); |
javax.servlet.http.HttpServletRequest |
long getDateHeader(String name); |
javax.servlet.http.HttpServletRequest |
String getHeader(String name); |
javax.servlet.http.HttpServletRequest |
Enumeration getHeaderNames(); |
javax.servlet.http.HttpServletRequest |
Enumeration getHeaders(String name); |
javax.servlet.http.HttpServletRequest |
int getIntHeader(String name); |
javax.servlet.http.HttpServletRequest |
String getMethod(); |
javax.servlet.http.HttpServletRequest |
String getPathInfo(); |
javax.servlet.http.HttpServletRequest |
String getPathTranslated(); |
javax.servlet.http.HttpServletRequest |
String getQueryString(); |
javax.servlet.http.HttpServletRequest |
String getRemoteUser(); |
javax.servlet.http.HttpServletRequest |
String getRequestURI(); |
javax.servlet.http.HttpServletRequest |
String getRequestedSessionId(); |
javax.servlet.http.HttpServletRequest |
String getServletPath(); |
javax.servlet.http.HttpServletRequest |
Principal getUserPrincipal(); |
javax.servlet.http.HttpServletRequest |
boolean isRequestedSessionIdFromCookie(); |
javax.servlet.http.HttpServletRequest |
boolean isRequestedSessionIdFromURL(); |
javax.servlet.http.HttpServletRequest |
boolean isRequestedSessionIdFromUrl(); |
javax.servlet.http.HttpServletRequest |
boolean isRequestedSessionIdValid(); |
javax.servlet.http.HttpServletRequest |
byte[] getURIAsBytes(); |
HTTPリクエストのURIをバイト配列として戻します。たとえば、HTTPリクエストの最初の行がGET /index.html HTTP/1.0である場合、/index.htmlをバイト配列として戻します。 |
long getInvokeTime(); |
サーブレットのサービス・メソッドがデータをクライアントへ書き戻すのにかかる時間を戻します。 |
int getResponseStatusCode(); |
javax.servlet.http.HttpServletResponse |
String getResponseHeader(String name); |
javax.servlet.http.HttpServletResponse |
例5-1 カスタムELFフィールドを作成するJavaクラス
import weblogic.servlet.logging.CustomELFLogger;
import weblogic.servlet.logging.FormatStringBuffer;
import weblogic.servlet.logging.HttpAccountingInfo;
/* This example outputs the User-Agent field into a
custom field called MyCustomField
*/
public class MyCustomField implements CustomELFLogger{
public void logField(HttpAccountingInfo metrics,
FormatStringBuffer buff) {
buff.appendValueOrDash(metrics.getHeader("User-Agent"));
}
}
サービス拒否攻撃とは、偽りのリクエストによってサーバーを過負荷状態にしようとする悪意ある試みです。一般的な攻撃の1つは、HTTP POSTメソッドで膨大な量のデータを送信するというものです。WebLogic Serverでは、3つの属性を設定して、この種の攻撃を防くことができます。これらの属性は、コンソールの「サーバー」または「仮想ホスト」で設定します。これらの属性を仮想ホストに対して設定した場合、その値は「サーバー」で設定した値をオーバーライドします。
HTTP POSTに含まれる大量のデータをWebLogic Serverが受信する間隔。
PostTimeoutSecsのデフォルト値は30です。
WebLogic ServerがPOSTデータを受信するために費やす最長時間。この制限を超えた場合、PostTimeoutExceptionがスローされ、次のメッセージがサーバー・ログに記録されます。
Post time exceeded MaxPostTimeSecs.
MaxPostTimeSecsのデフォルト値は30です。
単一のPOSTリクエストで受領するデータの最大バイト数。この制限を超えた場合、MaxPostSizeExceeded例外がスローされ、次のメッセージがサーバー・ログに記録されます。
POST size exceeded the parameter MaxPostSize.
HTTPエラー・コード413 (Request Entity Too Large)がクライアントに返されます。
クライアントがリスニング・モードの場合、クライアントはこれらのメッセージを取得します。クライアントがリスニング・モードでない場合は、接続は切断されます。
MaxPostSizeのデフォルト値は -1です。
HTTPトンネリングとは、HTTPプロトコルしか使用できないときに、WebLogic ServerとJavaクライアントの間にステートフルなソケット接続をシミュレートするための手段です。通常セキュリティ・ファイアウォール内のHTTPポートを「トンネリング」するために使用されます。HTTPはステートレスなプロトコルですが、WebLogic Serverはトンネリング機能を提供して接続を通常のT3Connectionのように見せかけます。しかし、通常のソケット接続に比べてパフォーマンスが若干低下する場合があります。
HTTPプロトコルでは、クライアントはリクエストを送信し、サーバーから応答を受信することしかできません。サーバーは自主的にクライアントと通信できず、プロトコルはステートレスです - これは、連続的な双方向接続ができないことを意味します。
WebLogic HTTPトンネリングは、HTTPプロトコル経由でT3Connectionをシミュレートすることによって、こうした制限を打開します。管理コンソールには、トンネリング接続を調整してパフォーマンスが向上するように構成できる属性がいくつかあります。接続に関する問題が発生しないかぎり、これらの制限を克服します。サーバーは、これらのプロパティを使用して、クライアント接続が有効であるかどうか、またはクライアントが有効であるかを判断します。
HTTPトンネリングを有効または無効にします。HTTPトンネリングはデフォルトでは無効です。
HTTPトンネリングを使用するには、サーバーでHTTPプロトコルとT3プロトコルの両方がサポートされている必要があります。
HTTPトンネリング接続が設定されると、クライアントは自動的にリクエストをサーバーに送信し、サーバーは自主的にクライアントにレスポンスできるようになります。また、クライアントはリクエストに指示を含めることができますが、この処理はクライアント・アプリケーションがサーバーと通信する必要があるかどうかに関係なく発生します。この属性で設定された秒数以内にサーバーがクライアントのリクエストに(アプリケーション・コードの一部として)応答しない場合、クライアントはその処理を行います。クライアントはレスポンスを受信し、自動的に別のリクエストを即座に送信します。
デフォルトは45秒で、有効な範囲は20 - 900秒です。
クライアントがサーバーに対して(レスポンスに対する)リクエストを最後に送信してから、この属性で設定された秒数が経過した場合、サーバーはクライアントを応答なしと見なしてHTTPトンネル接続を終了します。サーバーはこの属性によって指定された間隔で経過時間をチェックし、それまでにクライアントからリクエストがあればそれにレスポンスします。
デフォルトは40秒で、有効な範囲は10 - 900秒です。
クライアントが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用のリスニング・ポートは、管理コンソールの「サーバー」ノードの「ネットワーク」タブで指定します。
WebLogic ServerをWindows NT/2000/XPで実行している場合は、HTMLファイル、テキスト・ファイル、画像ファイルなどの静的ファイルを提供する際に、Javaメソッドではなくネイティブ・オペレーティング・システム・コールTransmitFileを使用するように指定できます。ネイティブ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が使用されます。このパラメータを指定しない場合のデフォルト値は4Kです。
ネイティブ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>
weblogic.http.nativeIOEnabledも、FileServletのコンテキスト・パラメータとして設定できます。
