| Oracle® Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション 11g リリース 1 (10.3.1) B55510-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション 11g リリース 1 (10.3.1) B55510-01 |
|
戻る |
次へ |
以下の節では、WebLogic Server でホストされている Java EE Web アプリケーションを、静的コンテンツをホストする標準の HTTP Web サーバとして機能するようにコンフィグレーションする方法について説明します。Web アプリケーションでは、JSP やサーブレットなどの動的コンテンツもホストできます。『Oracle Fusion Middleware 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 のように長時間にわたって実行するプロセスを、必要以上の特権で実行するのは望ましくありません。root 特権が必要なのは、ポートがバインドされるまでです。
weblogic.system.enableSetUID プロパティを (必要に応じて weblogic.system.enableSetGID プロパティも) true に設定することで、WebLogic Server がポート 80 にバインドした後に UNIX ユーザ ID (UID) を切り替えるための内部プロセスを有効にできます。これらに対応する weblogic.system.nonPrivUser プロパティと weblogic.system.nonPrivGroup プロパティには、WebLogic Server の起動後の実行に使用する特権のない UNIX ユーザ アカウント (必要に応じてグループ名) を指定します。
UNIX アカウントは、ほとんどの UNIX システムで特権が最も低い「nobody」に切り替えることができます。必要な場合は、WebLogic Server の実行専用の UNIX ユーザ アカウントを作成します。特権のないユーザは、WebLogic Server で必要になるファイル (ログ ファイル、WebLogic クラスなど) にアクセスできるように設定してください。WebLogic プロセスの所有権が特権のないユーザに切り替わると、WebLogic の読み込み、書き込み、および実行のパーミッションがそのユーザと同じになります。
リスン ポートは、非 SSL のリクエストとセキュアな (SSL を使用した) リクエストで別個に定義します。リスン ポートのコンフィグレーションの詳細については、「ネットワーク チャネルについて」を参照してください。
Administration Console を使用して、リスン ポートにポート 80 を設定します。「リスン ポートのコンフィグレーション」を参照してください。
WebLogic Server をホストしているマシンで Windows が動作している場合、手順 8 へ進みます。
Administration Console を使用して新しい UNIX マシンを作成します。「マシンの作成とコンフィグレーション」を参照してください。
[Post-Bind UID を有効化] フィールドをチェックします。
[Post-Bind UID] フィールドに、WebLogic Server を実行するユーザの名前を入力します。
[Post-Bind GID を有効化] フィールドをチェックします。
[Post-Bind GID] フィールドに、WebLogic Server を実行するグループの名前を入力します。
[Save] をクリックします。
Administration Console のチェンジ センタで [変更のアクティブ化] をクリックしてこれらの変更をアクティブ化します。
HTTP アプリケーションと Web アプリケーションは、Sun Microsystems のサーブレット仕様 2.4 および JSP 仕様 2.0 に従ってデプロイされます。これらの仕様では、Web アプリケーションが Web ベース アプリケーションのコンポーネントをグループ化するための標準として定義されています。これらのコンポーネントには、JSP ページ、HTTP サーブレット静的リソース (HTML ページや画像ファイルなど) が含まれます。また Web アプリケーションは、エンタープライズ EJB や JSP タグ ライブラリなどの外部リソースにアクセスすることもできます。各サーバは、任意の数の Web アプリケーションのホストになることができます。通常、Web アプリケーションの名前は、その Web アプリケーションのリソースを要求するために使う URI の一部として使用します。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』を参照してください。
Web アプリケーションは、WebLogic Server クラスタにデプロイできます。ユーザが Web アプリケーションのリソースを要求すると、そのリクエストはその Web アプリケーションがホストするクラスタ内のサーバの 1 つに転送されます。アプリケーションがセッション オブジェクトを使用する場合、そのセッションはクラスタ内の全サーバにレプリケートされなければなりません。セッションのレプリケートにはいくつかの方法があります。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』を参照してください。
ドメイン内のすべてのサーバ インスタンスおよび仮想ホストで、デフォルト Web アプリケーションを宣言できます。デフォルト Web アプリケーションは、デプロイされている別の Web アプリケーションによって解決できない任意の HTTP リクエストに応答します。他のすべての Web アプリケーションとは異なり、デフォルト Web アプリケーションの名前は、URI の一部として使用されません。サーバまたは仮想ホストに割り当てられた Web アプリケーションを、デフォルト Web アプリケーションとして宣言することができます (Web アプリケーションの割り当てについては、この節で後述します。仮想ホストの詳細については、「仮想ホスティングのコンフィグレーション」を参照してください)。
WebLogic Server に付属のサンプル ドメインでは、デフォルトの Web アプリケーションがすでにコンフィグレーションされています。このドメインのデフォルト Web アプリケーションは、DefaultWebApp という名前でドメインの applications ディレクトリに配置されています。
たとえば、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 アプリケーションを指定するには、application.xml または weblogic.xml ファイルのコンテキスト ルートを "" に設定します。
正常にデプロイされていないデフォルト Web アプリケーションを宣言すると、エラーがログに記録されるとともに、そのデフォルト Web アプリケーションにアクセスしようとしたユーザに対して HTTP 404 エラー メッセージが表示されます。
仮想ホスティングを使用すると、サーバまたはクラスタが応答するホスト名を定義できます。仮想ホスティングを使用するときは、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 アプリケーションが、それ以前に設定されていた JSESSIONID クッキーを上書きしてしまうためです。これは、すべてのデフォルト Web アプリケーションで CookieName、CookiePath、および CookieDomain をまったく同じにしても発生します。
仮想ホストを定義するには、Administration Console を使用して次の手順を実行します。「仮想ホスト」を参照してください。
仮想ホスト名を確実に解決できるように、サーバ上の etc/hosts ファイルに仮想ホストのネーミングの行を追加します。
WebLogic Server が HTTP リクエストを受信すると、WebLogic Server は、URL のさまざまな部分を解析し、その情報を利用してどの Web アプリケーションとサーバがそのリクエストを処理すべきかを決定することによって、そのリクエストを解決します。表 5-1 では、Web アプリケーション、仮想ホスト、サーブレット、JSP、および静的ファイルのリクエストのさまざまな組み合わせとその応答を示します。
|
注意 : Web アプリケーションをエンタープライズ アプリケーションの一部としてパッケージ化する場合は、Web アプリケーションへのリクエストの解決に使用する代わりの名前を指定できます。詳細については、『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「サーブレットのコンフィグレーション」を参照。 |
http://host:port/naval |
どちらでもよい |
詳細については、『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの以下のトピックを参照してください。
ログ ファイルは、そのファイルのサイズ、または指定した時間のいずれかに基づいてローテーションさせることができます。どちらかの条件が満たされると、現在のアクセス ログ ファイルが閉鎖され、新しいログ ファイルが開始されます。ログ ローテーションを設定しないと、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 通信に関する記録情報のタイプと順序を指定できます。このフォーマットを有効にするには、Administration Console の [HTTP] タブで、[フォーマット] 属性を [拡張] に設定します (「カスタム フィールド識別子の作成」を参照)。
このフォーマットでは、ログ ファイルに記録される情報のタイプをディレクティブによって指定します。ディレクティブは、実際のログ ファイルに組み込まれます。ディレクティブは、新しい行から「#」という記号で始まります。ログファイルが存在しない場合、デフォルト ディレクティブが記述された新しいログ ファイルが作成されます。しかし、サーバの起動時にログ ファイルがすでに存在する場合、そのファイルの先頭には有効なディレクティブが存在しなければなりません。
ログ ファイルの最初の行には、そのログ ファイル フォーマットのバージョン番号を示すディレクティブが存在しなければなりません。また、ファイルの先頭の近くには、Fields ディレクティブが存在しなければなりません。
#Version: 1.0 #Fields: xxxx xxxx xxxx ...
ここで各 xxxx は、記録されるデータ フィールドを表します。フィールド タイプは、W3C 仕様に定義されているとおり、単純な識別子として指定されるか、またはプレフィックス-識別子というフォーマットを取ります。次に例を示します。
#Fields: date time cs-method cs-uri
この識別子は、HTTP アクセスごとにトランザクションの日付と時間、クライアントが使用したリクエスト メソッド、およびリクエストの URI を記録するようサーバに指示します。各フィールドはスペースによって区切られ、各レコードは新しい行に書き込まれてログ ファイルに追加されます。
|
注意 : ログ ファイル内の#Fields ディレクティブの後には新しい行が続かなければなりません。これは、最初のログ メッセージがディレクティブと同じ行に追加されないようにするためです。 |
以下の識別子がサポートされています。プレフィックスは必要ありません。
トランザクションが完了した日付。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> です。
拡張ログ フォーマットを使用する 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://www.w3.org/TR/WD-logfile-960221.htmlの「Extended Log Format」を参照してください。 |
次のメソッドは HTTP リクエストに関するさまざまなデータを返します。これらのメソッドは、javax.servlet.ServletRequest、javax.servlet.http.Http.ServletRequest、および javax.servlet.http.HttpServletResponse のさまざまなメソッドと似ています。
こうしたインタフェースについての Javadoc は、以下の URL で参照できます。
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletRequest.html
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletResponse.html
http://java.sun.com/products/servlet/2.3/javadoc/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;
/* この例は User-Agent フィールドを 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 つの属性を設定して、この種の攻撃を防くことができます。3 つの属性は、コンソールの [サーバ] または [仮想ホスト] で設定します。これらの属性を仮想ホストに対して設定した場合、その値は [サーバ] で設定した値をオーバーライドします。
HTTP POST に含まれる大量のデータを WebLogic Server が受信する間隔。
PostTimeoutSecs のデフォルト値は 30 です。
WebLogic Server が POST データを受信するために費やす最長時間。この制限を超えた場合、PostTimeoutException が送出され、次のメッセージがサーバ ログに記録されます。
MaxPostTimeSecs のデフォルト値は 30 です。
単一の POST リクエストで受領するデータの最大バイト数。この制限を超えた場合、MaxPostSizeExceeded 例外が送出され、次のメッセージがサーバ ログに記録されます。
HTTP エラー コード 413 (Request Entity Too Large) がクライアントに返されます。
クライアントがリスン モードの場合、クライアントはこれらのメッセージを取得します。クライアントがリスン モードでない場合は、接続は切断されます。
MaxPostSize のデフォルト値は -1 です。
HTTP トンネリングとは、HTTP プロトコルしか使用できないときに、WebLogic Server と Java クライアントの間にステートフルなソケット接続をシミュレートするための手段です。HTTP トンネリングは、通常セキュリティ ファイアウォール内の HTTP ポートを「トンネリング」するために使用されます。HTTP はステートレスなプロトコルですが、WebLogic Server はトンネリング機能を提供して接続を通常の T3Connection のように見せかけます。しかし、通常のソケット接続に比べてパフォーマンスが若干低下する場合があります。
HTTP プロトコルでは、クライアントはリクエストを送信し、サーバから応答を受信することしかできません。一方、サーバも自主的にクライアントと通信できません。つまり、HTTP プロトコルはステートレスであり、連続的な双方向接続を行うことができません。
WebLogic HTTP トンネリングは、HTTP プロトコルを通して T3Connection をシミュレートすることによって、こうした制限を乗り越えます。トンネリング接続を調整してパフォーマンスを向上させるには、Administration Console で 2 つの属性を設定します。接続に関する問題が発生しない限り、これらの属性はデフォルトのままにしておくことをお勧めします。これらの属性は、クライアント接続が有効かどうか、またはクライアントが生存しているかどうかをサーバが調べるために使用されます。
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 用のリスン ポートは、Administration Console の [サーバ] ノードの [Network] タブで指定します。
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 のコンテキスト パラメータとして設定できます。
