HTTPリファレンス

デフォルトでは、 Quarkus はルートコンテキストの下からコンテンツを提供します。これを変更したい場合は、 quarkus.http.root-path 設定キーを使用してコンテキストパスを設定することができます。

Servlet を使用している場合は、quarkus.servlet.context-path を通して Servlet のコンテキストパスを制御することができます。この項目は、上記の http ルートに相対的で、Servlet と、Servlet の上で実行されるものにのみ影響します。多くのアプリケーションでは、Quarkus が提供するすべてのサービスに影響するため、HTTP ルートを使用することをお勧めします。

両方を指定した場合、サーブレット以外のすべてのウェブエンドポイントは quarkus.http.root-path からの相対的なものになり、サーブレットは {quarkus.http.root-path}/{quarkus.servlet.context-path} からの相対的なものになります。

テストに REST Assured を使用し、quarkus.http.root-path が設定されている場合、Quarkus は自動的に Quarkus テストで使用するためのベース URL を設定します。そのため、テストの URL はルートパスには含めないでください。

一般に、ウェブコンテンツのパス設定は、 quarkus.http.root-path ( デフォルトでは / ) からの相対パスとして解釈されます。

例として、エクステンションが service というパスを設定した場合、そのエンドポイントは ${quarkus.http.root-path}/service から提供されます。 そのパスの設定を /service に変更した場合、そのエンドポイントは /service から提供されるようになります。

Quarkus のパス解決に関するブログ記事では、ユーザー定義パスとエクステンション定義パスの両方に対するパス解決の仕組みについて詳しく説明しています。

Quarkusで安全な接続をサポートするには、証明書と関連するキーファイルを提供するか、キーストアを提供する必要があります。

いずれの場合も、パスワードを提供する必要があります。提供方法の詳細については、提供方法に関する段落を参照してください。

すべてのレスポンスに HTTP ヘッダーを送信するようにするには、以下のプロパティーを追加します。

これにより、アプリケーション内の任意のリソースに対して実行されるリクエストのレスポンスに、 X-Content-Type-Options: nosniff HTTP ヘッダーが含まれます。

また、ヘッダーを適用する必要がある path パターンと HTTP methods を指定することもできます。

これにより、 /headers/pragma リソースが GET または HEAD メソッドで呼び出された場合にのみ、 Pragma ヘッダーが適用されます。

100-continue をサポートするには、 quarkus.http.handle-100-continue-automatically オプションを明示的に有効にする必要があります。 詳細については、 100-continue と 関連する Vert.x ドキュメント を参照してください。

HTTP/2はデフォルトで有効になっており、SSLが使用されている場合はブラウザで使用されます。 SSL が使用されていない場合でも、クリアテキストアップグレードによる HTTP/2 はサポートされており、ブラウザ以外のクライアントで使用される可能性があります。

HTTP/2 を無効にしたい場合は、以下を設定します。

いくつかの設定属性はHTTP/2に固有であることに注意してください。例えば、最大ヘッダーリストサイズ (~ヘッダー) を設定するには、 quarkus.http.limits.max-header-list-size 属性を設定する必要があります。また、 quarkus.http.http2-push-enabled を使用して、HTTP/2プッシュを有効または無効にすることもできます。

ポートを指定したくない場合は、quarkus.http.port=0 または quarkus.http.test-port=0 を指定することができます。ランダムに開いているポートが OS によって選ばれ、コンソールにログメッセージが表示されます。ポートがバインドされると、quarkus.http.port システムプロパティーには選択された実際のポートが設定されます。そのため、これを利用して、アプリケーション内から実際のポート番号を取得できます。テスト中の場合は普通に URL を注入することができ、これは実際のポートで設定され、REST Assured も適切に設定されます。

Quarkusアプリケーションを別のドメインで実行されている別のアプリケーションからアクセスできるようにするには、クロスオリジンリソース共有（CORS）を設定する必要があります。 Quarkusが提供するCORSフィルターの詳細については、クロスオリジンリソース共有ガイドのQuarkus CORSフィルター のセクションを参照してください。

トラフィックシェーピングを使用すると、開いているチャネルの数に関係なく、すべてのチャネル（つまり接続）の帯域幅を制限することができます。 これは、ネットワーク全体のトラフィックを制御して輻輳を防止したり、特定の種類のトラフィックを優先したりする場合に便利です。

トラフィック・シェーピングを有効にするには、アプリケーション・コンフィグレーションに以下のプロパティを追加する：

トラフィックシェーピングでは、書き込みと読み取りの制限（1秒あたりのバイト数）、チェック間隔（帯域幅の2回の計算間の遅延）、最大待機時間など、さまざまなパラメータを設定できます：

チェック間隔は、トラフィックが計算される期間を表し、間隔が大きいほど、トラフィックシェーピングの精度が低くなる可能性があります。 0が受け入れられるにもかかわらず（アカウンティングなし）、トラフィックシェーピングの精度はトラフィックが計算される期間に依存するため、チェック間隔には高くても正の値を設定することを推奨します。 この場合、5分または10分に近い値が推奨されます。

outbound-global-bandwidth 、 inbound-global-bandwidth パラメータは、それぞれ書き込みと読み出し操作の1秒あたりの最大バイト数を表します。 また、読み取りまたは書き込み操作のオブジェクト・サイズを、必要な帯域幅に比較的適合させることも考慮する必要があります。 例えば、10KB/秒に対して10MBのオブジェクトがあるとバースト効果が生じますが、1MB/秒に対して100KBのオブジェクトがあれば、トラフィックシェーピングによってスムーズに処理できるはずです。

さらに、最大待機時間 ( max-delay ) を設定できます。これは、タイムシェーピングの上限を指定するものです。 デフォルトでは 15 秒に設定されています。 これは HTTP タイムアウトより小さくなければなりません。 しきい値のいずれかに達すると、その期間書き込みは行われません。

application.properties で設定することで、HTTP リクエストのロギングを追加することができます。ロギングには、標準の JBoss ロギング出力にロギングするか、専用ファイルにロギングするかの 2 つのオプションがあります。

修飾子 < のサポートを有効にするには quarkus.http.access-log.consolidate-rerouted-requests=true を設定します。この修飾子は、元のリクエストを参照するために内部的にリダイレクトされた リクエストに使用できます。 以下の属性がこの修飾子をサポートしています：

Quarkusでは、 io.quarkus.vertx.http.HttpServerOptionsCustomizer を使用して、Quarkusが起動するHTTPサーバーのオプションを任意にカスタマイズできます。 例えば、HTTPポートをプログラムで設定する必要がある場合、次のコードを使用できます:

Quarkus は、プロキシーサーバーが関与すると変更されたり失われたりするクライアント側の情報を保持するために、追加でヘッダー ( 例： X-Forwarded-Host ) を生成するプロキシーを介してアクセスされる可能性があります。このようなシナリオでは、 Quarkus は、これらのヘッダーの値を反映して、プロトコル、ホスト、ポート、 URI などの情報を自動的に更新するように設定することができます。

この機能を設定するには、 src/main/resources/application.properties に以下の行を記述してください。

デファクトスタンダードのヘッダー ( Forwarded header ) だけを考慮するためには、 src/main/resources/application.properties に以下の行を記述してください。

非標準のヘッダーのみを考慮するには、代わりに以下の行を src/main/resources/application.properties に記述してください。

標準ヘッダーと非標準ヘッダーに関連する設定はどちらも組み合わせることが できるますが、標準ヘッダーの設定が優先されます。しかしながら、これらを組み合わせることは、クライアントがプロキシにーよって上書きされない転送 ( forward ) ヘッダーを持つリクエストを偽造することができるため、セキュリティ上の影響があります。したがって、プロキシーはクライアントから予期しない X-Forwarded ヘッダまたは X-Forwarded-* ヘッダを取り除く必要があります。

サポートされている転送アドレスヘッダーは以下の通りです。

例えば、クッキー名と SameSite 属性を記載することで、 Quarkus のエンドポイントによって設定された任意のクッキーに SameSite クッキープロパティを簡単に追加することができます。

この設定では、 jwt クッキーは SameSite=Lax 属性を持ち、 session クッキーは SameSite=Strict 属性を持つことになります。

サーブレットを使用するには、明示的に quarkus-undertow を含める必要があります。