第17章 Web サーバーの設定 (Undertow)

17.1. Undertow サブシステムの概要

重要

JBoss EAP 7 では、JBoss EAP 6 の web サブシステムの代わりに undertow サブシステムが使用されます。

undertow サブシステムは、Web サーバーおよびサーブレットコンテナーの設定を可能にします。Jakarta Servlet 4.0 Specification や WebSocket を実装します。HTTP のアップグレードや、サーブレットデプロイメントでの高パフォーマンスな非ブロッキングハンドラーの使用もサポートします。undertow サブシステムは、mod_cluster をサポートする高パフォーマンスなリバースプロキシとして動作することも可能です。

undertow サブシステム内で設定する主なコンポーネントは 5 つあります。

注記

JBoss EAP には、これらの各コンポーネントの設定を更新する機能がありますが、デフォルト設定は妥当なパフォーマンスの設定を提供し、ほとんどのユースケースに適しています。

デフォルトの Undertow サブシステムの設定

<subsystem xmlns="urn:jboss:domain:undertow:10.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
        <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <http-invoker security-realm="ApplicationRealm"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
        <websockets/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
</subsystem>
重要

また、undertow サブシステムは io サブシステムに依存して XNIO ワーカーやバッファープールを提供します。io サブシステムは個別に設定され、ほとんどの場合で最適なパフォーマンスを得られるデフォルト設定を提供します。

注記

JBoss EAP 6 の web サブシステムと比較すると、JBoss EAP 7 の undertow サブシステムでは HTTP メソッドのデフォルト動作が異なります。

Undertow サブシステムでの Elytron の使用

web アプリケーションがデプロイされると、そのアプリケーションが必要なセキュリティードメインの名前が特定されます。これは、デプロイメント内からで、デプロイメントにセキュリティードメインがない場合は undertow サブシステムで定義された default-security-domain が仮定されます。デフォルトでは、セキュリティードメインがレガシー security サブシステムで定義された PicketBox にマップすることが仮定されます。しかし、アプリケーションが必要なセキュリティードメインの名前から適切な Elytron 設定にマッピングする undertow サブシステムに application-security-domain リソースを追加することができます。

例: マッピングの追加

/subsystem=undertow/application-security-domain=ApplicationDomain:add(security-domain=ApplicationDomain)

マッピングの追加に成功すると、以下のような結果が出力されます。

<subsystem xmlns="urn:jboss:domain:undertow:10.0" ... default-security-domain="other">
...
    <application-security-domains>
        <application-security-domain name="ApplicationDomain" security-domain="ApplicationDomain"/>
    </application-security-domains>
...
</subsystem>

注記
  • この時点でデプロイメントがすでにデプロイされている場合は、アプリケーションサーバーをリロードして、アプリケーションセキュリティードメインマッピングを有効にする必要があります。
  • 現在の Web サービス/Elytron 統合では、Web サービスエンドポイントと Elytron セキュリティードメイン名をセキュアにするために指定されたセキュリティードメインの名前が同じである必要があります。

この簡単な例は、BASICCLIENT_CERTDIGESTFORM など、デプロイメントがサーブレット仕様内で定義された標準の HTTP メカニズムを使用する場合に適しています。この場合、認証は ApplicationDomain セキュリティードメインに対して実行されます。このフォームは、アプリケーションが認証メカニズムを使用せず、代わりにプログラムによる認証を使用したり、デプロイメントに関連する SecurityDomain を取得して直接使用したりする場合にも適しています。

例: 高度なマッピング

/subsystem=undertow/application-security-domain=MyAppSecurity:add(http-authentication-factory=application-http-authentication)

高度なマッピングに成功すると、以下のような結果が出力されます。

<subsystem xmlns="urn:jboss:domain:undertow:10.0" ... default-security-domain="other">
...
    <application-security-domains>
        <application-security-domain name="MyAppSecurity" http-authentication-factory="application-http-authentication"/>
    </application-security-domains>
...
</subsystem>

このような設定では、セキュリティードメインを参照する代わりに、http-authentication-factory が参照されます。これは、認証メカニズムのインスタンスの取得に使用されるファクトリーで、セキュリティードメインと関連付けられます。

カスタム HTTP 認証メカニズムを使用する場合や、プリンシパルトランスフォーマー、認証情報ファクトリー、メカニズムレルムなどのメカニズムに追加の設定を定義する必要がある場合など、http-authentication-factory 属性を参照する必要があります。また、Servlet 仕様に記載されている 4 つのメカニズム以外を使用する場合は、http-authentication-factory 属性を参照した方がよいでしょう。

高度なマッピングが使用される場合、別の設定オプション override-deployment-config を使用できます。参照された http-authentication-factory は認証メカニズムの完全セットを返すことができます。デフォルトでは、アプリケーションによってリクエストされたメカニズムと一致するするためにフィルターされます。このオプションが true に設定された場合、ファクトリーによって提供されたメカニズムは、アプリケーションによってリクエストされたメカニズムをオーバーライドします。

application-security-domain リソースには追加のオプション enable-jacc もあります。これを true に設定すると、このマッピングに一致するすべてのデプロイメントに対して JACC が有効になります。

ランタイム情報

application-security-domain マッピングが使用されている場合、このマッピングに対してデプロイメントが想定どおり一致していることを再度確認すると便利です。リソースが include-runtime=true で読み取りされた場合、マッピングに関連するデプロイメントは以下のように表示されます。

/subsystem=undertow/application-security-domain=MyAppSecurity:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "enable-jacc" => false,
        "http-authentication-factory" => undefined,
        "override-deployment-config" => false,
        "referencing-deployments" => ["simple-webapp.war"],
        "security-domain" => "ApplicationDomain",
        "setting" => undefined
    }
}

この出力の referencing-deployments 属性は、simple-webapp.war デプロイメントがマッピングを使用してデプロイされたことを示しています。

17.2. バッファーキャッシュの設定

バッファーキャッシュは静的リソースをキャッシュするために使用されます。JBoss EAP では複数のキャッシュを設定でき、デプロイメントによる参照が可能であるため、デプロイメントごとに異なるキャッシュサイズを使用することができます。バッファーは固定サイズで、リージョンで割り当てられます。使用領域の合計は、バッファーサイズ、リージョンごとのバッファー数、およびリージョンの最大数を掛けて算出できます。バッファーキャッシュのデフォルトサイズは 10MB です。

JBoss EAP はデフォルトで単一のキャッシュを提供します。

デフォルトの Undertow サブシステムの設定

<subsystem xmlns="urn:jboss:domain:undertow:10.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
    <buffer-cache name="default"/>
    ...
</subsystem>

既存のバッファーキャッシュの更新

既存のバッファーキャッシュを更新するには、以下を指定します。

/subsystem=undertow/buffer-cache=default/:write-attribute(name=buffer-size,value=2048)
reload

新規バッファーキャッシュの作成

新しいバッファーキャッシュを作成するには、以下を指定します。

/subsystem=undertow/buffer-cache=new-buffer:add

バッファーキャッシュの削除

バッファーキャッシュを削除するには、以下を指定します。

/subsystem=undertow/buffer-cache=new-buffer:remove
reload

バッファーキャッシュの設定に使用できる属性の完全リストは、「Undertow サブシステムの属性」の項を参照してください。

17.3. バイトバッファープールの設定

Undertow バイトバッファープールは、プールされた NIO ByteBuffer インスタンスの割り当てに使用されます。すべてのリスナーにバイトバッファープールがあり、各リスナーに異なるバッファープールおよびワーカーを使用できます。バイトバッファープールは異なるサーバーインスタンス間で共有できます。

これらのバッファーは IO 操作に使用され、バッファーサイズはアプリケーションのパフォーマンスに大きく影響します。通常、ほとんどのサーバーでは 16 K が理想のサイズになります。

既存のバイトバッファープールの更新

既存のバイトバッファープールを更新するには、以下を指定します。

/subsystem=undertow/byte-buffer-pool=myByteBufferPool:write-attribute(name=buffer-size,value=1024)
reload

バイトバッファープールの削除

新しいバイトバッファープールを作成するには、以下を指定します。

/subsystem=undertow/byte-buffer-pool=newByteBufferPool:add

バイトバッファープールの削除

バイトバッファープールを削除するには、以下を指定します。

/subsystem=undertow/byte-buffer-pool=newByteBufferPool:remove
reload

バイトバッファープールの設定に使用できる属性の完全リストは「バイトバッファープールの属性」を参照してください。

17.4. サーバーの設定

サーバーは Undertow のインスタンスを表し、複数の要素で構成されます。

  • host
  • http-listener
  • https-listener
  • ajp-listener

ホスト要素は仮想ホスト設定を提供し、3 つのリスナーはそのタイプの接続を Undertow インスタンスに提供します。

サーバーのデフォルトの動作では、サーバーの起動中にリクエストをキューに置きます。デフォルトの動作を変更するには、ホストで queue-requests-on-start 属性を使用します。この属性がデフォルトの true に設定されている場合、サーバーの起動時に到達するリクエストはサーバーの準備が整うまで保留されます。この属性が false に設定された場合、サーバーが完全に起動する前に到達したリクエストは、デフォルトの応答コードで拒否されます。

属性の値に関わらず、サーバーが完全に起動するまでリクエストの処理は開始されません。

管理コンソールを使用して queue-requests-on-start 属性を設定するには、ConfigurationSubsystemsWeb (Undertow)Server と選択した後、サーバーを選択して 表示 をクリックし、Hosts タブを選択します。管理対象ドメイでは、設定するプロファイルを指定する必要があります。

注記

複数のサーバーを設定できるため、デプロイメントやサーバーを完全に分離できます。これは、マルチテナント環境などで便利です。

JBoss EAP はデフォルトでサーバーを提供します。

デフォルトの Undertow サブシステムの設定

<subsystem xmlns="urn:jboss:domain:undertow:10.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
        <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <http-invoker security-realm="ApplicationRealm"/>
        </host>
    </server>
    ...
</subsystem>

以下の例は、管理 CLI を使用してサーバーを設定する方法を示しています。管理コンソールを使用してサーバーを設定する場合は、ConfigurationSubsystemsWeb (Undertow)Server と選択します。

既存のサーバーの更新

既存のサーバーを更新するには、以下を設定します。

/subsystem=undertow/server=default-server:write-attribute(name=default-host,value=default-host)
reload

新規サーバーの作成

新規サーバーを作成するには、以下を指定します。

/subsystem=undertow/server=new-server:add
reload

サーバーの削除

サーバーを削除するには、以下を指定します。

/subsystem=undertow/server=new-server:remove
reload

サーバーの設定に使用できる属性の完全リストは、「Undertow サブシステムの属性」の項を参照してください。

17.4.1. アクセスロギング

定義する各ホストにアクセスロギングを設定できます。

利用できるアクセスロギングオプションは、標準のアクセスロギングとコンソールアクセスロギングの 2 つです。

アクセスロギングに必要な追加の処理はシステムパフォーマンスに影響を与える可能性があることに注意してください。

17.4.1.1. 標準のアクセスロギング

標準のアクセスログは、ログエントリーをログファイルに書き込みます。

デフォルトでは、ログファイルは standalone/log/access_log.log ディレクトリーに保存されます。

標準のアクセスログを有効にするには、アクセスログデータを取得するホストに access-log 設定を追加します。以下の CLI コマンドは、デフォルトの JBoss EAP サーバーのデフォルトのホストの設定を示しています。

/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add
注記

標準のアクセスログを有効にしたら、サーバーをリロードする必要があります。

デフォルトでは、アクセスログレコードには以下のデータが含まれます。

  • リモートホスト名
  • リモート論理ユーザー名 (常に -)
  • 認証されたリモートユーザー
  • Common Log Format 形式のリクエストの日時
  • 要求の最初の行
  • 応答の HTTP ステータスコード
  • HTTP ヘッダーを除く、送信済みバイト数。

この一連のデータは共通のパターンとして定義されます。組み合わせた別のパターンも使用できます。一般的なパターンでログ記録されているデータのほかに、組み合わせたパターンには、受信ヘッダーからの閲覧元およびユーザーエージェントが含まれます。

ログに記録されるデータは、pattern 属性を使用して変更できます。以下の CLI コマンドは、組み合わせたパターンを使用ための pattern 属性の更新を示しています。

/subsystem=undertow/server=default-server/host=default-host/setting=access-log:write-attribute(name=pattern,value="combined"
注記

pattern 属性を更新した後は、サーバーをリロードする必要があります。

表17.1 利用可能なパターン

パターン説明

%A

リモート IP アドレス

%A

ローカル IP アドレス

%b

送信済みバイト数 (HTTP ヘッダーまたは - を除く (バイトが送信されなかった場合))

%B

送信済みバイト数 (HTTP ヘッダーを除く)

%h

リモートホスト名

%H

要求プロトコル

%l

identd からのリモート論理ユーザー名 (常に - を返します。これは、Apache アクセスログの互換性のために含まれています)

%m

要求メソッド

%p

ローカルポート

%q

クエリー文字列 (? 文字を除く)

%r

要求の最初の行

%s

応答の HTTP ステータスコード

%t

Common Log Format 形式の日時

%u

認証されたリモートユーザー

%U

要求された URL パス

%v

ローカルサーバー名

%D

要求を処理するのにかかった時間 (ミリ秒単位)

%T

要求を処理するのにかかった時間 (秒単位)

%I

現在の要求スレッド名 (後でスタックトレースと比較できます)

common

%h %l %u %t "%r" %s %b

combined

%h %l %u %t "%r" %s %b "%{i,Referer}" "%{i,User-Agent}"

cookie、受信ヘッダーおよび応答ヘッダー、またはセッションから情報を書き込むこともできます。これは、Apache 構文に基づきます。

  • %{i,xxx} (受信ヘッダーの場合)
  • %{o,xxx} (送信応答ヘッダーの場合)
  • %{c,xxx} (特定のクッキーの場合)
  • %{r,xxx} (xxxServletRequest の属性)
  • %{s,xxx} (xxxHttpSession の属性)

このログには、追加の設定オプションも利用できます。詳細は、付録の「access-log 属性」を参照してください。

17.4.1.2. コンソールアクセスロギング

コンソールのアクセスログは、JSON データとして構造化された標準出力 (stdout) にデータを書き込みます。

各アクセスログレコードは、1行のデータです。ログ集約システムにより、このデータを取得して処理できます。

コンソールアクセスロギングを設定するには、アクセスログデータをキャプチャーしたいホストに console-access-log 設定を追加します。以下の CLI コマンドは、デフォルトの JBoss EAP サーバーのデフォルトのホストの設定を示しています。

/subsystem=undertow/server=default-server/host=default-host/setting=console-access-log:add

デフォルトでは、コンソールアクセスログレコードには以下のデータが含まれます。

表17.2 デフォルトのコンソールアクセスログデータ

ログデータフィールド名説明

eventSource

リクエストのイベントのソース

hostname

要求を処理した JBoss EAP ホスト

bytesSent

JBoss EAP サーバーがリクエストへの応答として送信したバイト数

DateTime

要求が JBoss EAP サーバーによって処理された日時 JBoss EAP サーバーがリクエストを処理した日時

remoteHost

要求の発信先のマシンの IP アドレス

remoteuser

リモート要求に関連付けられたユーザー名

requestLine

送信された要求

responseCode

JBoss EAP サーバーによって返された HTTP 応答コード

デフォルトプロパティーはログ出力に常に含まれます。attributes 属性を使用して、デフォルトのログデータのラベルを変更できます。場合によっては、データ設定を変更することも可能です。attributes 属性を使用して、さらにログデータを出力に追加することもできます。

表17.3 利用可能なコンソールアクセスログデータ

ログデータフィールド名説明形式

authentication-type

要求に関連付けられたユーザーの認証に使用される認証タイプデフォルトラベル: authenticationType。このキーオプションを使用して、このプロパティーのラベルを変更します。

authentication-type{} authentication-type={key="authType"}

bytes-sent

リクエストに対して返されるバイト数。HTTP ヘッダーを除く。デフォルトラベル: bytesSent。このキーオプションを使用して、このプロパティーのラベルを変更します。

bytes-sent={} bytes-sent={key="sent-bytes"}

date-time

要求が受信および処理された日時。デフォルトラベル: dateTime。このキーオプションを使用して、このプロパティーのラベルを変更します。date-format を使用して、日付レコードのフォーマットに使用するパターンを定義します。このパターンは Java SimpleDateFormatter パターンである必要があります。date-format オプションが定義されている場合は、time-zone オプションを使用して日付や時間データのフォーマットに使用するタイムゾーンを指定します。この値は有効な java.util.TimeZone である必要があります。

date-time={key="<keyname>", date-format="<date-time format>"} date-time={key="@timestamp", date-format="yyyy-MM-dd’T’HH:mm:sSSS"}

host-and-port

リクエストによってクエリーされたホストおよびポート。デフォルトラベル: hostAndPort。このキーオプションを使用して、このプロパティーのラベルを変更します。

host-and-port{} host-and-port={key="port-host"}

local-ip

ローカル接続の IP アドレス。このキーオプションを使用して、このプロパティーのラベルを変更します。デフォルトラベル: locallp。このキーオプションを使用して、このプロパティーのラベルを変更します。

local-ip{} local-ip{key=”localIP”}

local-port

ローカル接続のポート。デフォルトラベル: localPort。このキーオプションを使用して、このプロパティーのラベルを変更します。

local-port{} local-port{key=”LocalPort”}

local-server-name

要求を処理したローカルサーバー名。デフォルトラベル: localServerName。このキーオプションを使用して、このプロパティーのラベルを変更します。

local-server-name {} local-server-name {key=LocalServerName}

path-parameter

リクエストに含まれる 1 つ以上のパスまたは URI パラメーター。name プロパティーは、交換値を解決するために使用される名前のコンマ区切りリストです。key-prefix プロパティーを使用してキーを一意にします。key-prefix が指定されている場合は、出力の各 path パラメーター名の前にプレフィックスが追加されます。

path-parameter{names={store,section}} path-parameter{names={store,section}, key-prefix=”my-”}

predicate

述語コンテキストの名前。name プロパティーは、交換値を解決するために使用される名前のコンマ区切りリストです。key-prefix プロパティーを使用してキーを一意にします。key-prefix が指定されている場合は、出力の各 path パラメーター名の前にプレフィックスが追加されます。

predicate{names={store,section}} predicate{names={store,section}, key-prefix=”my-”}

query-parameter

リクエストに含まれる 1 つ以上のパラメーターまたはクエリーパラメーター。names プロパティーは、交換値を解決するために使用される名前のコンマ区切りリストです。key-prefix プロパティーを使用してキーを一意にします。key-prefix が指定されている場合は、出力の各 path パラメーター名の前にプレフィックスが追加されます。

query-parameter{names={store,section}} query-parameter{names={store,section}, key-prefix=”my-”}

query-string

リクエストのクエリー文字列。デフォルトラベル: localPort。このキーオプションを起用して、このプロパティーのラベルを変更します。include-question-mark プロパティーを使用して、クエリー文字列に疑問符を含めるかどうかを指定します。デフォルトでは、疑問符は含まれていません。

query-string{} query-string{key=”QueryString”, include-question-mark=”true”}

relative-path

要求の相対パス。デフォルトラベル: relativePath。このキーオプションを使用して、このプロパティーのラベルを変更します。

relative-path{} relative-path{key=”RelativePath”}

remote-host

リモートホスト名デフォルトラベル: remotehost。このキーオプションを使用して、このプロパティーのラベルを変更します。

remote-host{} remote-host{key=”RemoteHost”}

remote-ip

リモート IP アドレス。デフォルトラベル: remoteIp。このキーオプションを使用して、このプロパティーのラベルを変更します。この難読化プロパティーを使用して、出力ログレコードの IP アドレスを難読化します。デフォルト値は false です。

remote-ip{} remote-ip{key=”RemoteIP”, obfuscated=”true”}

remote-user

認証されたリモートユーザーデフォルトラベル: remoteuser。このキーオプションを使用して、このプロパティーのラベルを変更します。

remote-user{} remote-user{key=”RemoteUser”}

request-header

要求ヘッダーの名前。構造化されたデータのキーはヘッダーの名前です。その値は名前付きヘッダーの値になります。names プロパティーは、交換値を解決するために使用される名前のコンマ区切りリストです。key-prefix プロパティーを使用してキーを一意にします。key-prefix が指定されている場合には、出力の要求ヘッダー名の前にプレフィックスが追加されます。

request-header{names={store,section}} request-header{names={store,section}, key-prefix=”my-”}

request-line

リクエストの行。デフォルトラベル: requestLine。このキーオプションを使用して、このプロパティーのラベルを変更します。

request-line{} request-line{key=”Request-Line”}

request-method

要求メソッドデフォルトラベル: requestMethod。このキーオプションを使用して、このプロパティーのラベルを変更します。

request-method{} request-method{key=”RequestMethod”}

request-path

リクエストの相対パス。デフォルトラベル: requestPath。このキーオプションを使用して、このプロパティーのラベルを変更します。

request-path{} request-path{key=”RequestPath”}

request-protocol

要求のプロトコル。デフォルトラベル: requestProtocol。このキーオプションを使用して、このプロパティーのラベルを変更します。

request-protocol{} request-protocol{key=”RequestProtocol”}

request-scheme

要求の URI スキーム。デフォルトラベル: requestScheme。このキーオプションを使用して、このプロパティーのラベルを変更します。

request-scheme{} request-scheme{key=”RequestScheme”}

request-url

元の要求 URI。クライアントで指定した場合、ホスト名、プロトコルなどが含まれます。デフォルトラベル: requestUrl。このキーオプションを使用して、このプロパティーのラベルを変更します。

request-url{} request-url{key=”RequestURL”}

resolved-path

解決したパス。デフォルトラベル: resolvedPath。このキーオプションを使用して、このプロパティーのラベルを変更します。

resolved-path{} resolved-path{key=”ResolvedPath”}

response-code

応答コード。デフォルトラベル: responseCode。このキーオプションを使用して、このプロパティーのラベルを変更します。

response-code{} response-code{key=”ResponseCode”}

response-header

応答ヘッダーの名前。構造化されたデータのキーはヘッダーの名前です。その値は名前付きヘッダーの値になります。names プロパティーは、交換値を解決するために使用される名前のコンマ区切りリストです。key-prefix プロパティーを使用してキーを一意にします。key-prefix が指定されている場合には、出力の要求ヘッダー名の前にプレフィックスが追加されます。

response-header{names={store,section}} response-header{names={store,section}, key-prefix=”my-”}

response-reason-phrase

応答コードのテキスト理由。デフォルトラベル: responseReasonPhrase。このキーオプションを使用してこのプロパティーのラベルを変更します。

response-reason-phrase{} response-reason-phrase{key=”ResponseReasonPhrase”}

response-time

リクエストの処理に使われる時間。デフォルトラベル: responseTime。このキーオプションを使用して、このプロパティーのラベルを変更します。デフォルトの時間単位はミリ秒 (MILLISECONDS) です。利用可能な時間の単位は以下のとおりです。* NANOSECONDS * MICROSECONDS * MILLISECONDS * SECONDS

response-time{} response-time{key=”ResponseTime”, time-unit=SECONDS}

secure-exchange

交換がセキュアであったかどうかを示します。デフォルトラベル: secureExchange。このキーオプションを使用して、このプロパティーのラベルを変更します。

secure-exchange{} secure-exchange{key=”SecureExchange”}

ssl-cipher

要求の SSL 暗号。デフォルトラベル: sslCipher。このオプションを使用して、このプロパティーのラベルを変更します。

ssl-cipher{} ssl-cipher{key=”SSLCipher”}

ssl-client-cert

要求の SSL クライアント証明書。デフォルトラベル: sslclientcert。このキーオプションを使用して、このプロパティーのラベルを変更します。

ssl-client-cert{} ssl-client-cert{key=”SSLClientCert”}

ssl-session-id

要求の SSL セッション ID。デフォルトラベル: sslSessionId。このキーオプションを使用して、このプロパティーのラベルを変更します。

ssl-session-id{} stored-response

要求に対する、保存した応答。デフォルトラベル: storedResponse。このキーオプションを使用して、このプロパティーのラベルを変更します。

stored-response{} stored-response{key=”StoredResponse”}

thread-name

現在のスレッドのスレッド名。デフォルトラベル: threadName。このキーオプションを使用して、このプロパティーのラベルを変更します。

thread-name{} thread-name{key=”ThreadName”}

transport-protocol

metadata 属性を使用して、アクセスログレコードに追加する追加の任意のデータを設定できます。metadata 属性の値は、アクセスログレコードに追加するデータを定義する key:value ペアのセットです。ペアのこの値は管理モデルの式になります。管理モデル式は、サーバーの起動またはリロード時に解決されます。キーと値のペアはカンマで区切られます。

以下の CLI コマンドは、追加のログデータ、ログデータのカスタマイズ、追加のメタデータなど、複雑なコンソールログ設定の例を示しています。

/subsystem=undertow/server=default-server/host=default-host/setting=console-access-log:add(metadata={"@version"="1", "qualifiedHostName"=${jboss.qualified.host.name:unknown}}, attributes={bytes-sent={}, date-time={key="@timestamp", date-format="yyyy-MM-dd'T'HH:mm:ssSSS"}, remote-host={}, request-line={}, response-header={key-prefix="responseHeader", names=["Content-Type"]}, response-code={}, remote-user={}})

結果として生成されるアクセスログレコードは以下の追加の JSON データに類似しています (注意: 以下の出力例は、読みやすさを考慮してフォーマットされています。実際の記録では、すべてのデータが単一の行として出力されます)。

{
    "eventSource":"web-access",
    "hostName":"default-host",
    "@version":"1",
    "qualifiedHostName":"localhost.localdomain",
    "bytesSent":1504,
    "@timestamp":"2019-05-02T11:57:37123",
    "remoteHost":"127.0.0.1",
    "remoteUser":null,
    "requestLine":"GET / HTTP/2.0",
    "responseCode":200,
    "responseHeaderContent-Type":"text/html"
}

以下のコマンドは、コンソールアクセスログを有効にした後にのログデータへの更新を示しています。

/subsystem=undertow/server=default-server/host=default-host/setting=console-access-log:write-attribute(name=attributes,value={bytes-sent={}, date-time={key="@timestamp", date-format="yyyy-MM-dd'T'HH:mm:ssSSS"}, remote-host={}, request-line={}, response-header={key-prefix="responseHeader", names=["Content-Type"]}, response-code={}, remote-user={}})

以下のコマンドは、コンソールアクセスログを有効にした後にカスタムメタデータへの更新を示しています。

/subsystem=undertow/server=default-server/host=default-host/setting=console-access-log:write-attribute(name=metadata,value={"@version"="1", "qualifiedHostName"=${jboss.qualified.host.name:unknown}}

17.5. サーブレットコンテナーの設定

サーブレットコンテナーは、すべてのサーブレット、 JSP、およびソケット関連の設定 (セッションに関連する設定を含む) を提供します。ほとんどのサーバーにはサーブレットコンテナーが 1 つだけ必要ですが、servlet-container 要素を追加すると複数のサーブレットコンテナーを設定することができます。サーブレットコンテナーが複数設定されていると、複数のデプロイメントを異なる仮想ホストの同じコンテキストパスにデプロイできるなど、一部の動作を有効にすることができます。

注記

サーブレットコンテナーによって提供される設定の多くは、デプロイされたアプリケーションが web.xml ファイルを使用して個別にオーバーライドできます。

JBoss EAP はデフォルトでサーブレットコンテナーを提供します。

デフォルトの Undertow サブシステムの設定

<subsystem xmlns="urn:jboss:domain:undertow:10.0">
  <buffer-cache name="default"/>
  <server name="default-server">
    ...
  </server>
  <servlet-container name="default">
      <jsp-config/>
      <websockets/>
  </servlet-container>
...
</subsystem>

以下の例は、管理 CLI を使用してサーブレットコンテナーを設定する方法を示しています。管理コンソールを使用してサーブレットコンテナーを設定する場合は、ConfigurationSubsystemsWeb (Undertow)Servlet Container と選択します。

既存のサーブレットコンテナーの更新

既存のサーブレットコンテナーを更新するには、以下を指定します。

/subsystem=undertow/servlet-container=default:write-attribute(name=ignore-flush,value=true)
reload

新規サーブレットコンテナーの作成

新規のサーブレットコンテナーを作成するには、以下を指定します。

/subsystem=undertow/servlet-container=new-servlet-container:add
reload

サーブレットコンテナーの削除

サーブレットコンテナーを削除するには、以下を指定します。

/subsystem=undertow/servlet-container=new-servlet-container:remove
reload

サーブレットコンテナーの設定に使用できる属性の完全リストは、「Undertow サブシステムの属性」の項を参照してください。

17.6. サーブレット拡張の設定

サーブレット拡張は、サーブレットデプロイメントプロセスへのフックや、サーブレットデプロイメントの変更を可能にします。これは、追加の認証メカニズムをデプロイメントに追加する必要がある場合や、ネイティブ Undertow ハンドラーをサーブレットデプロイメントの一部として使用する必要がある場合などに便利です。

カスタムサーブレット拡張を作成するには、io.undertow.servlet.ServletExtension インターフェースを実装した後、実装クラスの名前をデプロイメントの META-INF/services/io.undertow.servlet.ServletExtension ファイルに追加する必要があります。さらに、ServletExtension 実装のコンパイルされたクラスファイルを含める必要もあります。Undertow がサーブレットをデプロイすると、deployments クラスローダーからすべてのサービスをロードし、それらの handleDeployment メソッドを呼び出します。

デプロイメントの完全かつ変更可能な記述が含まれる Undertow DeploymentInfo 構造は、このメソッドに渡されます。この構造を変更して、デプロイメントの内容を変更することができます。

DeploymentInfo 構造は、組み込み API によって使用される構造と同じあるため、ServletExtension は Undertow を組み込みモードで使用したときと同じ柔軟性を持ちます。

17.7. ハンドラーの設定

JBoss EAP では、2 つのタイプのハンドラーを設定できます。

  • ファイルハンドラー
  • リバースプロキシーハンドラー

ファイルハンドラーは静的ファイルに対応します。各ファイルハンドラーは仮想ホストの場所にアタッチされている必要があります。リバースプロキシーハンドラーによって、JBoss EAP は高パフォーマンスなリバースプロキシーとして機能することができます。

JBoss EAP はデフォルトでファイルハンドラーを提供します。

デフォルトの Undertow サブシステムの設定

<subsystem xmlns="urn:jboss:domain:undertow:10.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
    <buffer-cache name="default"/>
    <server name="default-server">
        ...
    </server>
    <servlet-container name="default">
        ...
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
</subsystem>

静的リソースに WebDAV を使用

過去のバージョンの JBoss EAP では、web サブシステムで WebDAV を使用して (WebdavServlet 経由) 静的リソースをホストし、追加の HTTP メソッドを有効にしてこれらのファイルへのアクセスや操作を実行できました。JBoss EAP 7 では、ファイルハンドラーを経由した静的ファイルの対応メカニズムは undertow サブシステムによって提供されますが、undertow サブシステムは WebDAV をサポートしません。JBoss EAP 7 で WebDAV を使用する場合は、カスタムの WebDav サーブレットを記述してください。

既存のファイルハンドラーの更新

既存のファイルハンドラーを更新するには、以下を指定します。

/subsystem=undertow/configuration=handler/file=welcome-content:write-attribute(name=case-sensitive,value=true)
reload

新規ファイルハンドラーの作成

新規のファイルハンドラーを作成するには、以下を指定します。

/subsystem=undertow/configuration=handler/file=new-file-handler:add(path="${jboss.home.dir}/welcome-content")
警告

ファイルハンドラーの path を直接ディレクトリーではなくファイルに設定した場合、そのファイルハンドラーを参照する location 要素の最後にフォワードスラッシュ (/) を付けないでください。最後にフォワードスラッシュが付くと、404 - Not Found が返されます。

ファイルハンドラーの削除

ファイルハンドラーを削除するには、以下を指定します。

/subsystem=undertow/configuration=handler/file=new-file-handler:remove
reload

ハンドラーの設定に使用できる属性の完全リストは、「Undertow サブシステムの属性」の項を参照してください。

17.8. フィルターの設定

フィルターはリクエストの一部の変更を可能にし、述語を使用してフィルターの実行時を制御できます。フィルターの一般的なユースケースには、ヘッダーの設定や GZIP 圧縮などがあります。

注記

フィルターの機能は、JBoss EAP 6 で使用されたグローバルバルブと同等です。

以下のタイプのフィルターを定義できます。

  • custom-filter
  • error-page
  • expression-filter
  • gzip
  • mod-cluster
  • request-limit
  • response-header
  • rewrite

以下の例は、管理 CLI を使用してフィルターを設定する方法を示しています。管理コンソールを使用してフィルターを設定する場合は、ConfigurationSubsystemsWeb (Undertow)Filters と選択します。

既存のフィルターの更新

既存のフィルターを更新するには、以下を指定します。

/subsystem=undertow/configuration=filter/response-header=myHeader:write-attribute(name=header-value,value="JBoss-EAP")
reload

新規のフィルターの作成

新規のフィルターを作成するには、以下を指定します。

/subsystem=undertow/configuration=filter/response-header=new-response-header:add(header-name=new-response-header,header-value="My Value")

フィルターの削除

フィルターを削除するには、以下を指定します。

/subsystem=undertow/configuration=filter/response-header=new-response-header:remove
reload

フィルターの設定に使用できる属性の完全リストは「Undertow サブシステムの属性」の項を参照してください。

17.8.1. buffer-request ハンドラーの設定

クライアントまたはブラウザーからのリクエストは、ヘッダーとボディーの 2 つで構成されます。通常の場合、ヘッダーとボディーの間に遅延がない状態で JBoss EAP に送信されます。しかし、ヘッダーが最初に送信され、その数秒後にボディーが送信されると、完全なリクエストの送信に遅延が発生します。このような場合、JBoss EAP にスレッドが作成され、完全なリクエストの実行を待機していることを示す waiting が表示されます。

リクエストのヘッダーおよびボティーの送信による遅延は、buffer-request ハンドラーを使用して修正できます。buffer-request ハンドラーは、ワーカースレッドに割り当てする前に、非ブロッキング IO スレッドからリクエストの消費を試みます。追加された buffer-request ハンドラーがない場合、スレッドは直接ワーカースレッドに割り当てられます。しかし、buffer-request ハンドラーが追加されると、ワーカースレッドに割り当てする前に、ハンドラーは IO スレッドを使用してブロックせずにバッファー処理できる量のデータを読み取ろうとします。

以下の管理 CLI コマンドを使用して buffer-request ハンドラーを設定できます。

/subsystem=undertow/configuration=filter/expression-filter=buf:add(expression="buffer-request(buffers=1)")

/subsystem=undertow/server=default-server/host=default-host/filter-ref=buf:add

処理できるバッファーリクエストのサイズには制限があります。この制限は、以下の式のとおり、バッファーサイズとバッファー合計数の組み合わせで決定されます。

Total_size = num_buffers × buffer_size

この式の説明は次のとおりです。

  • Total_size は、リクエストがワーカースレッドに送信される前にバッファー処理されるデータのサイズになります。
  • num_buffers はバッファーの数になります。バッファーの数は、ハンドラーの buffers パラメーターによって設定されます。
  • buffer_size は各バッファーのサイズになります。バッファーサイズは io サブシステムで設定され、デフォルトではリクエストごとに 16KB になります。
警告

メモリー不足になる可能性があるため、サイズが大きすぎるバッファーリクエストは設定しないでください。

17.9. デフォルトの Welcome Web アプリケーションの設定

JBoss EAP には、デフォルトではポート 8080 のルートコンテキストで表示されるデフォルトの Welcome アプリケーションが含まれます。

Undertow には、Welcome コンテンツに対応するデフォルトのサーバーが事前設定されています。

デフォルトの Undertow サブシステムの設定

<subsystem xmlns="urn:jboss:domain:undertow:10.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
    ...
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
        <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <http-invoker security-realm="ApplicationRealm"/>
        </host>
    </server>
    ...
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
</subsystem>

デフォルトのサーバー default-server にはデフォルトのホスト default-host が設定されています。デフォルトのホストは、welcome-content ファイルハンドラーで <location> 要素を使用して、サーバーのルートへのリクエストを処理するよう設定されています。welcome-content ハンドラーは path プロパティーに指定された場所でコンテンツを処理します。

このデフォルトの Welcome アプリケーションは、独自の Web アプリケーションで置き換えることができます。これは、以下の 2 つのいずれかの方法で設定できます。

Welcome コンテンツを無効にすることもできます。

welcome-content ファイルハンドラーの変更

  1. 新しいデプロイメントを参照する、既存の welcome-content ファイルハンドラーのパスを変更します。

    /subsystem=undertow/configuration=handler/file=welcome-content:write-attribute(name=path,value="/path/to/content")
    注記

    または、サーバーのルートにより使用される異なるファイルハンドラーを作成することもできます。

    /subsystem=undertow/configuration=handler/file=NEW_FILE_HANDLER:add(path="/path/to/content")
    /subsystem=undertow/server=default-server/host=default-host/location=\/:write-attribute(name=handler,value=NEW_FILE_HANDLER)
  2. 変更を反映するためにサーバーをリロードします。

    reload

default-web-module の変更

  1. デプロイされた Web アプリケーションをサーバーのルートにマップします。

    /subsystem=undertow/server=default-server/host=default-host:write-attribute(name=default-web-module,value=hello.war)
  2. 変更を反映するためにサーバーをリロードします。

    reload

デフォルトの Welcome Web アプリケーションの無効化

  1. default-hostlocation エントリー (/) を削除して welcome アプリケーションを無効にします。

    /subsystem=undertow/server=default-server/host=default-host/location=\/:remove
  2. 変更を反映するためにサーバーをリロードします。

    reload

17.10. HTTPS の設定

Web アプリケーションの HTTPS 設定に関する詳細は、『How to Configure Server Security』の「Configure One-way and Two-way SSL/TLS for Applications」を参照してください。

JBoss EAP 管理インターフェースと使用するための HTTPS 設定に関する詳細は、『How to Configure Server Security』の「How to Secure the Management Interfaces」を参照してください。

17.11. HTTP セッションタイムアウトの設定

HTTP セッションタイムアウトは、HTTP セッションの無効を宣言するために必要な非アクティブな期間を定義します。たとえば、HTTP セッションを作成する JBoss EAP にデプロイされたアプリケーションにユーザーがアクセスしたとします。HTTP セッションタイムアウト後に同じユーザーが同じアプリケーションに再度アクセスしようとすると、元の HTTP セッションは無効化され、ユーザーは新しい HTTP セッションの作成を強制されます。これにより、永続化されなかったデータを損失したり、ユーザーを再認証する必要がある場合があります。

HTTP セッションタイムアウトは、アプリケーションの web.xml ファイルに設定されますが、デフォルトの HTTP セッションタイムアウトは JBoss EAP 内で指定できます。サーバーのタイムアウト値はデプロイされたすべてのアプリケーションに適用されますが、アプリケーションの web.xml はサーバーの値をオーバーライドします。

サーバーの値は、undertow サブシステムの servlet-container セクションにある default-session-timeout プロパティーに指定されます。default-session-timeout の値は分単位で指定され、デフォルトは 30 です。

デフォルトのセッションタイムアウトの設定

default-session-timeout を設定するには、以下を指定します。

/subsystem=undertow/servlet-container=default:write-attribute(name=default-session-timeout, value=60)
reload

17.12. HTTP のみのセッション管理クッキーの設定

セッション管理クッキーは、JavaScript などの HTTP API および非 HTTP API の両方によってアクセスされます。JBoss EAP は HttpOnly ヘッダーを Set-Cookie 応答ヘッダーの一部としてクライアント (通常はブラウザー) に送信します。サポートされるブラウザーでこのヘッダーを有効にすると、非 HTTP API を経由してセッション管理クッキーへアクセスしないようにブラウザーに通知します。セッション管理クッキーを HTTP API のみに制限すると、クロスサイトスクリプティングの攻撃よるセッションクッキーの窃盗のリスクを軽減することができます。この動作を有効にするには、http-only 属性を true に設定する必要があります。

重要

HttpOnly ヘッダーを使用しても、単にブラウザーに通知を行うだけで、クロスサイトスクリプティングによる攻撃を実際に防ぐわけではありません。この動作を反映するには、ブラウザーも HttpOnly をサポートしている必要があります。

重要

HttpOnly 属性を使用すると制限がセッション管理クッキーのみに適用され、その他のブラウザークッキーには適用されません。

http-only 属性は undertow サブシステムの 2 カ所で設定されます。

  • セッションクッキー設定としてサーブレットコンテナーで設定
  • 単一のサインオンプロパティーとしてサーバーのホストセクションで設定

host-only プロパティーをサーブレットコンテナーセッションクッキーに設定するには、以下を指定します。

/subsystem=undertow/servlet-container=default/setting=session-cookie:add
/subsystem=undertow/servlet-container=default/setting=session-cookie:write-attribute(name=http-only,value=true)
reload

host-only をホストシングルサインオンに設定

host-only プロパティーをホストシングルサインオンに設定するには、以下を指定します。

/subsystem=undertow/server=default-server/host=default-host/setting=single-sign-on:add
/subsystem=undertow/server=default-server/host=default-host/setting=single-sign-on:write-attribute(name=http-only,value=true)
reload

17.13. HTTP/2 の設定

Undertow では、HTTP/2 標準を使用できます。この標準は、ヘッダーの圧縮と多くのストリームの多重化を同じ TCP 接続で行い、待ち時間を削減します。さらに、リクエストの前にサーバーがリソースをクライアントにプッシュできる機能も提供するため、ページのロードがより速くなります。

HTTP/2 は、HTTP/2 標準をサポートするクライアントとブラウザーでのみ機能することに注意してください。

重要

最新のブラウザーは、h2 と呼ばれるセキュアな TLS 接続上の HTTP/2 を強制します。h2c と呼ばれるプレーン HTTP 上の HTTP/2 はサポートしないことがあります。h2c で HTTP/2 を使用するように JBoss EAP を設定することが可能です。つまり、HTTPS を使用せずに HTTP のアップグレードでプレーン HTTP のみを使用します。この場合、Undertow の HTTP リスナーで HTTP/2 を有効にします。

/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=enable-http2,value=true)

HTTP/2 を使用するよう Undertow を設定するには、enable-http2 属性を true に設定し、HTTP/2 を使用するよう Undertow の HTTPS リスナーを有効にします。

/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enable-http2,value=true)

HTTPS リスナーの情報や、Web アプリケーションで HTTPS を使用するよう Undertow を設定する方法については、『How to Configure Server Security』の「Configure One-way and Two-way SSL/TLS for Applications」を参照してください。

注記

elytron サブシステムで HTTP/2 を使用するには、Undertow の https-listener にある設定済みの ssl-context が変更可能として設定される必要があります。これには、適切な server-ssl-contextwrap 属性を false に設定します。デフォルトでは wrap 属性は false に設定されます。これは、ALPN に関する ssl-context の変更を行うために Undertow で必要になります。提供された ssl-context が書き込み可能でない場合、ALPN は使用できず、接続は HTTP/1.1 にフォールバックします。

HTTP/2 使用時の ALPN サポート

セキュアな TLS 接続上で HTTP/2 を使用する場合、ALPN TLS プロトコル拡張をサポートする TLS スタックが必要になります。このスタックの取得はインストールされた JDK によって異なります。

  • Java 8 を使用する場合、ALPN 実装は Java 内部に依存して直接 JBoss EAP に導入されます。そのため、ALPN 実装は Oracle および OpenJDK でのみ動作します。IBM Java では動作しません。Red Hat は、ALPN 機能を実装する OpenSSL ライブラリーとともに、OpenSSL プロバイダーからの ALPN TLS プロトコル拡張サポートを JBoss EAP で使用することを推奨します。OpenSSL プロバイダーの ALPN TLS プロトコル拡張サポートを使用すると、パフォーマンスが向上します。
  • Java 9 より、JDK は ALPN をネイティブでサポートするようになりましたが、Java 9 以上を使用する場合でも OpenSSL プロバイダーからの ALPN TLS プロトコル拡張サポートを使用するとパフォーマンスが向上されるはずです。

ALPN TLS プロトコル拡張サポートを取得するための OpenSSL のインストール手順は、「JBoss Core Services からの OpenSSL のインストール」を参照してください。標準のシステム OpenSSL は Red Hat Enterprise Linux 8 でサポートされており、追加の JBoss Core Services OpenSSL は必要ありません。

OpenSSL がインストールされたら、「OpenSSL を使用するよう JBoss EAP を設定」にある手順にしたがいます。

HTTP/2 が使用されていることを検証

Undertow が HTTP/2 を使用していることを検証するには、Undertow からのヘッダーを確認する必要があります。https を使用して JBoss EAP インスタンスに移動し (例: https://localhost:8443)、ブラウザーの開発者ツールを使用してヘッダーを確認します。Google Chrome などの一部のブラウザーは、HTTP/2 の使用時には :path:authority:method:scheme などの HTTP/2 擬似ヘッダーを表示します。Firefox や Safari などの他のブラウザーは、ヘッダーの状態またはバージョンを HTTP/2.0 と表示します。

17.14. RequestDumping ハンドラーの設定

RequestDumping ハンドラーである io.undertow.server.handlers.RequestDumpingHandler は、JBoss EAP 内で Undertow によって処理されるリクエストとその応答オブジェクトの詳細をログに記録します。

重要

このハンドラーはデバッグに便利ですが、機密情報がログに記録される可能性があります。この点に留意してこのハンドラーを有効にしてください。

注記

RequestDumping ハンドラーは、JBoss EAP 6 の RequestDumperValve の代わりに使用されます。

RequestDumping ハンドラーは、JBoss EAP のサーバーレベルまたは個別のアプリケーション内のいずれかで設定できます。

17.14.1. サーバーでの RequestDumping ハンドラーの設定

RequestDumping ハンドラーは式フィルターとして設定する必要があります。RequestDumping ハンドラーを式フィルターとして設定するには、以下を行う必要があります。

RequestDumping ハンドラーで新しい式フィルターを作成する
/subsystem=undertow/configuration=filter/expression-filter=requestDumperExpression:add(expression="dump-request")
Undertow Web サーバーで式フィルターを有効にする
/subsystem=undertow/server=default-server/host=default-host/filter-ref=requestDumperExpression:add
重要

このように RequestDumping ハンドラーを式フィルターとして有効にすると、Undertow Web サーバーによって処理されるすべてのリクエストおよびそれらの応答がログに記録されます。

特定 URL に対して RequestDumping ハンドラーを設定する

すべてのリクエストをログに記録する他に、特定の URL のリクエストやそれらの応答のみをログに記録するために式フィルターを使用することもできます。これには、pathpath-prefixpath-suffix などの述語を式に使用します。たとえば、/myApplication/test へのリクエストとそれらの応答をすべてログに記録するには、式フィルターの作成時に式 "dump-request" の代わりに "path(/myApplication/test) -> dump-request" を使用します。これにより、/myApplication/test に完全一致するパスを持つリクエストのみが RequestDumping ハンドラーに送られます。

17.14.2. アプリケーション内での RequestDumping ハンドラーの設定

サーバーで RequestDumping ハンドラーを設定する他に、個別のアプリケーション内で設定することもできます。これにより、ハンドラーの範囲がそのアプリケーションのみに制限されます。RequestDumping ハンドラーは WEB-INF/undertow-handlers.conf で設定する必要があります。

指定のアプリケーションのすべてのリクエストとそれらの応答をログに記録するよう WEB-INF/undertow-handlers.confRequestDumping ハンドラーを設定するには、以下の式を WEB-INF/undertow-handlers.conf に追加します。

例: WEB-INF/undertow-handlers.conf

dump-request

指定のアプリケーション内での特定 URL のリクエストやそれらの応答のみをログに記録するよう、WEB-INF/undertow-handlers.confRequestDumping ハンドラーを設定するには、pathpath-prefixpath-suffix などの述語を式に使用します。たとえば、アプリケーションの test へのリクエストとそれらの応答をすべてログに記録するには、path 述語が含まれる以下の式を使用できます。

例: WEB-INF/undertow-handlers.conf

path(/test) -> dump-request

注記

pathpath-prefixpath-suffix などの述語をアプリケーションの WEB-INF/undertow-handlers.conf に定義された式で使用する場合、使用する値はアプリケーションのコンテキストルートからの相対値になります。たとえば、アプリケーションのコンテキストルートは myApplication で、式 path(/test) -> dump-requestWEB-INF/undertow-handlers.conf に設定されている場合、/myApplication/test へのリクエストとそれらの応答のみがログに記録されます。

17.16. Undertow サブシステムの調整

undertow サブシステムのパフォーマンスを最適化するための情報は、『パフォーマンスチューニングガイド』の「Undertow サブシステムの調整」を参照してください。