413 リクエスト エンティティが大きすぎる - TooBigBody

Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントに移動します。 情報

症状

クライアント アプリケーションが、API 呼び出しに対するレスポンスとして、エラーコード protocol.http.TooBigBody 付きの HTTP ステータス コード 413 Request Entity Too Large を受け取ります。

エラー メッセージ

クライアント アプリケーションは、次のレスポンス コードを受け取ります。

HTTP/1.1 413 Request Entity Too Large

さらに、次のエラー メッセージも確認できます。

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

考えられる原因

このエラーは、クライアント アプリケーションから Apigee Edge に送信された HTTP リクエストの一部であるペイロード サイズが、Apigee Edge で許可されている上限を超えている場合に発生します。

このエラーの原因として、以下のことが考えられます。

原因 説明 トラブルシューティングの実施対象
リクエストのペイロード サイズが上限を超えている Apigee Edge への HTTP リクエストの一部としてクライアント アプリケーションによって送信されたペイロード サイズが、Apigee Edge で許可されている上限を超えている。 Edge Public Cloud と Private Cloud のユーザー
リクエストのペイロード サイズが解凍後の上限を超えている Apigee Edge への HTTP リクエストの一部としてクライアント アプリケーションによって圧縮形式で送信されたペイロード サイズが、Apigee Edge によって解凍されたときに許可されている上限を超えている。 Edge Public Cloud と Private Cloud のユーザー

共通の診断手順

次のいずれかのツールまたは手法を使用して、このエラーを診断します。

API Monitoring

API Monitoring を使用してエラーを診断するには:

  1. 適切なロールを持つユーザーとして Apigee Edge UI にログインします。

  2. 問題を調査する組織に切り替えます

  3. [Analyze] > [API Monitoring] > [Investigate] ページに移動します。
  4. エラーが発生した特定の期間を選択します。
  5. [Proxy] フィルタを選択して、障害コードを絞り込むことができます。
  6. 障害コードと時間をプロットします。

  7. 次のように、障害コード protocol.http.TooBigBody とステータス コード 413 を含むセルを選択します。

  8. 障害コード protocol.http.TooBigBody に関する情報が次のように表示されます。

  9. [ログを表示] をクリックし、失敗したリクエストの行を開きます。[ログ] ウィンドウで、以下に示すように詳細を確認します。

    非圧縮

    シナリオ #1: リクエスト ペイロードが非圧縮形式で送信される

    [ログ] ウィンドウで、次の詳細をメモします。

    • ステータス コード: 413
    • 障害の発生元: proxy
    • 障害コード: protocol.http.TooBigBody。
    • リクエストの長さ（バイト）: 15360440（約 15 MB）

    Fault Source の値が proxy、Fault Code の値が protocol.http.TooBigBody、Request Length が 10 MB を超えている場合、クライアントからの HTTP リクエストのペイロード サイズが Apigee で許可されている上限を超えていることを示します。

    圧縮

    シナリオ #2: 圧縮形式で送信されたリクエスト ペイロード

    [ログ] ウィンドウで、次の詳細を確認します。

    • ステータス コード: 413
    • 障害の発生元: proxy
    • 障害コード: protocol.http.TooBigBody。
    • リクエストの長さ（バイト）: 15264（約 15 KB）

    Fault Source の値が proxy、Fault Code の値が protocol.http.TooBigBody、Request Length が 10 MB 未満の場合、クライアントからの HTTP リクエストの ペイロード サイズが、圧縮形式では Apigee で許可されている上限を下回っているものの、Apigee で圧縮解除すると ペイロード サイズが許可されている上限を超えていることを示します。

トレース

Trace ツールを使用してエラーを診断するには:

  1. トレース セッションと、次のいずれかを有効にします。
    • 413 Request Entity Too Large エラーが発生するまで待つか、
    • 問題を再現できる場合は、API 呼び出しを行い、413 Request Entity Too Large エラーを再現します。

  2. [Show all Flow Infos] が有効になっていることを確認します。

  3. 失敗したリクエストのいずれかを選択し、トレースを確認します。
  4. フェーズ [Request Received from Client]（クライアントからリクエストを受信）に移動します。

    非圧縮

    シナリオ #1: リクエスト ペイロードが非圧縮形式で送信される

    次の点にご注意ください。

    • Content-Encoding: なし
    • Content-Length: 15360204

    圧縮

    シナリオ #2: 圧縮形式で送信されたリクエスト ペイロード

    次の点にご注意ください。

    • Content-Encoding: gzip
    • Content-Length: 14969
    • Content-Type: application/x-gzip
  5. トレースのさまざまなフェーズを調べて、障害が発生した場所を特定します。

  6. 通常、エラーは次の図に示すように、[Request Received from Client]（クライアントからリクエストを受信）フェーズの後のフローに表示されます。

  7. トレースからエラーの値をメモします。上記のトレース サンプルは、次のことを示しています。
    • エラー: Body buffer overflow
    • error.class: com.apigee.errors.http.user.RequestTooLarge

  8. [Response Sent to Client] に移動し、トレースからエラーの値をメモします。次のトレース例は、以下を示しています。

    • エラー: 413 Request Entity Too Large
    • エラー コンテンツ: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
  9. トレースの AX（Analytics Data Recorded）フェーズに移動してクリックします。

  10. [Phase Details] セクションで、[Variables Read] まで下にスクロールします。

  11. 変数 client.received.content.length の値を決定します。この変数は次のことを示します。
    • 非圧縮形式で送信されたリクエスト ペイロードの実際のサイズ。
    • ペイロードが圧縮形式で送信された場合に、Apigee による解凍後のリクエスト ペイロードのサイズ。このシナリオでは、常に許可された上限（10 MB）の値と同じになります。

    非圧縮

    シナリオ #1: 圧縮されていない形式のリクエスト ペイロード

    client.received.content.length 変数: 15360204

    圧縮

    シナリオ 2: 圧縮形式のリクエスト ペイロード

    client.received.content.length 変数: 10489856

  12. 次の表は、client.received.content.length 変数の値に基づいて、2 つのシナリオで Apigee が 413 エラーを返す理由を示しています。
    シナリオ client.received.content.length の値 失敗の理由
    非圧縮形式のリクエスト ペイロード ～ 15 MB サイズが上限の 10 MB を超えている。
    圧縮形式のリクエスト ペイロード 約 10 MB

    解凍時にサイズの上限を超えた

NGINX

NGINX アクセスログを使用してエラーを診断するには:

  1. Private Cloud ユーザーの場合は、NGINX アクセスログを使用して、HTTP 413 エラーに関する重要な情報を特定できます。

  2. NGINX アクセスログを確認します。

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  3. 特定の期間に 413 エラーが発生したかどうか（問題が過去に発生した場合）、または 413 で失敗しているリクエストがまだあるかどうかを検索します。
  4. X-Apigee-fault-code が protocol.http.TooBigBody の値と一致する 413 エラーが見つかった場合は、X-Apigee-fault-source の値を特定します。

    非圧縮

    シナリオ 1 : 非圧縮形式のリクエスト ペイロード サイズ

    上記の NGINX アクセスログのエントリ例では、X-Apigee-fault-code と X-Apigee-fault-source に次の値が設定されています。

    レスポンス ヘッダー 値
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-sourc policy

    リクエストの長さ: 15360440（14.6 MB > 許容上限）

    圧縮

    シナリオ #2 : 圧縮形式のリクエスト ペイロード サイズ

    上記の NGINX アクセスログのサンプル エントリには、X-Apigee-fault-code と X-Apigee-fault-source に次の値が設定されています。

    レスポンス ヘッダー 値
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source policy

    リクエストの長さ: 15264（14.9 K < 許容上限）と表示されます。

    このシナリオでは、リクエストの長さが許容上限を下回っていても、Apigee Edge は 413 を返します。これは、リクエストが圧縮形式で送信され、Apigee Edge による解凍時にペイロードのサイズが上限を超えている可能性があるためです。

原因: リクエストのペイロード サイズが許容上限を超えている

診断

  1. 一般的な診断手順のシナリオ 1（非圧縮）で説明されているように、API Monitoring、Trace ツール、または NGINX アクセスログを使用して確認されたエラーの障害コード、障害ソース、リクエスト ペイロード サイズを特定します。
  2. Fault Source の値が policy または proxy の場合、クライアント アプリケーションから Apigee に送信されたリクエスト ペイロードのサイズが Apigee Edge で許可されている上限を超えていることを示します。
  3. ステップ 1 で特定したリクエスト ペイロード サイズを確認します。
  4. 次の手順で実際のリクエストを確認して、リクエスト ペイロード サイズが実際に 10 MB の制限を超えているかどうかを検証することもできます。
    1. クライアント アプリケーションによって行われた実際のリクエストにアクセスできない場合は、解決策に進みます。
    2. クライアント アプリケーションから送信された実際のリクエストにアクセスできる場合は、次の手順を行います。
      1. リクエストで渡されたペイロードのサイズを確認します。
      2. ペイロードのサイズが Apigee Edge で許可されている上限を超えている場合、それが問題の原因です。

        3. リクエストの例:

        curl http://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile -v

        上記の例では、ファイル test15mbfile は約 15 MB です。別のクライアントを使用している場合は、クライアントログを取得して、送信されるペイロードのサイズを確認します。

解決策

解決策に移動します。

原因: リクエストのペイロード サイズが、解凍後に許容上限を超えている

リクエスト ペイロードが圧縮形式で送信され、リクエスト ヘッダー Content-Encoding が gzip, に設定されている場合、Apigee はリクエスト ペイロードを解凍します。解凍プロセス中に、Apigee がペイロードのサイズが 10 MB（ 許可された上限）を超えていることを検出すると、それ以上の解凍を停止し、エラーコード protocol.http.TooBigBody で 413 Request Entity Too Large をすぐに返します。

診断

  1. 一般的な診断手順のシナリオ 2（圧縮）で説明したように、API Monitoring、Trace Tool、NGINX アクセスログを使用して、エラーの障害コード、障害の発生元、 リクエスト ペイロード サイズ を特定します。
  2. Fault Source の値が policy または proxy の場合、これは、クライアント アプリケーションから Apigee に送信されたリクエスト ペイロード サイズが Apigee Edge で許可されている上限を超えていることを示します。
  3. ステップ 1 で決定した Request Payload Size を確認します。
    • ペイロード サイズが上限の 10 MB を超えている場合、それがエラーの原因です。
    • ペイロード サイズが 10 MB の上限を下回っている場合は、リクエスト ペイロードが圧縮形式で渡されている可能性があります。この場合は、圧縮されたリクエスト ペイロードの非圧縮サイズを確認します。
  4. 次のいずれかの方法を使用して、クライアントからのリクエストが圧縮形式で送信され、非圧縮サイズが許容制限を超えているかどうかを検証できます。

    トレース

    Trace ツールを使用して検証するには:

    1. 失敗したリクエストのトレースをキャプチャした場合は、トレースと
      1. client.received.content.length 変数の値を特定する
      2. クライアントからのリクエストに Content-Encoding: gzip ヘッダーが含まれているかどうかを確認します。
    2. client.received.content.length 変数の値が 10 MB（ 許容上限）を超えており、リクエスト ヘッダー Content-Encoding: gzip が存在する場合、このエラーの原因はそれです。

    実際のリクエスト

    実際のリクエストを使用して検証するには:

    1. クライアント アプリケーションによって行われた実際のリクエストにアクセスできない場合は、解決策に進みます。
    2. クライアント アプリケーションによって行われた実際のリクエストにアクセスできる場合は、次の手順を行います。
      1. リクエストで渡されるペイロードのサイズと、リクエストで送信される Content-Encoding ヘッダーを確認します。

      2. ペイロードの非圧縮サイズが Apigee Edge で許容される上限を超えているかどうかを確認します。

        リクエストの例:

        curl https://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile.gz -H "Content-Encoding: gzip" -v

        上記の例では、ファイル test15mbfile.gz はサイズ上限を下回っていますが、非圧縮ファイル test15mbfile のサイズは約 15 MB で、Content-Encoding ヘッダーは gzip です。

        別のクライアントを使用している場合は、クライアント ログを取得して、送信されるペイロードのサイズと Content-Encoding ヘッダーが gzip に設定されているかどうかを確認します。

    Message Processor ログ

    Message Processor のログを使用して検証するには:

    1. Private Cloud ユーザーの場合は、Message Processor のログを使用して、HTTP 413 エラーに関する重要な情報を特定できます。

    2. Message Processor のログを確認します。

      /opt/apigee/var/log/edge-message-processor/logs/system.log

    3. 特定の期間に 413 エラーが発生したかどうか（問題が過去に発生した場合）、または 413 で失敗しているリクエストがまだあるかどうかを検索します。

      次の検索文字列を使用できます。

      grep -ri "chunkCount"

      grep -ri "RequestTooLarge"
    4. system.log から次のような行が見つかります（TotalRead と chunkCount は場合によって異なります）。
      2021-07-06 13:29:57,544  NIOThread@1 ERROR HTTP.SERVICE -
  TrackingInputChannel.checkMessageBodyTooLarge()
  : Message is too large.  TotalRead 10489856 chunkCount 2570

2021-07-06 13:29:57,545  NIOThread@1 INFO  HTTP.SERVICE -
  ExceptionHandler.handleException()
  : Exception trace: com.apigee.errors.http.user.RequestTooLarge
  : Body buffer overflow
    5. 解凍プロセス中、Message Processor は読み取りバイト数の合計が 10 MB を超えたと判断すると、停止して次の行を出力します。
      Message is too large.  TotalRead 10489856 chunkCount 2570

      これは、リクエスト ペイロード サイズが 10 MB を超えており、サイズが 10 MB の上限を超え始めると、Apigee がエラー RequestTooLarge をスローし、障害コードが protocol.http.TooBigBody になることを意味します。

解決策

サイズを固定

オプション 1 [推奨]: 許可されている上限を超えるペイロード サイズを送信しないようにクライアント アプリケーションを修正する

  1. 上限で定義されているように、特定のクライアントが許可されている上限を超えるリクエスト / ペイロード サイズを送信する理由を分析します。

  2. 望ましくない場合は、リクエスト / ペイロード サイズが許容上限を下回るようにクライアント アプリケーションを変更します。

    上記の例では、次のように小さいサイズのファイル（test5mbfile、サイズ 5 MB）のペイロードを渡すことで、問題を修正できます。

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
  3. 上限を超えてリクエストやペイロードを送信する必要がある場合は、次のオプションに進みます。

署名付き URL パターン

オプション 2 [推奨]: Apigee JavaCallout 内で署名付き URL パターンを使用する

10 MB を超えるペイロードには、GitHub の Edge Callout: Signed URL Generator の例に示されている、Apigee JavaCallout に含まれる署名付き URL パターンを使用することをおすすめします。

ストリーミング

オプション 3 : ストリーミングを使用する

API プロキシで非常に大きなリクエストやレスポンスを処理する必要がある場合は、Apigee でストリーミングを有効にできます。

CwC

オプション 4 : CwC プロパティを使用してバッファの上限を増やす

このオプションは、推奨オプションをいずれも使用できない場合にのみ使用してください。デフォルトのサイズを大きくすると、パフォーマンスの問題が発生する可能性があります。

Apigee には、リクエストとレスポンスのペイロード サイズの上限を引き上げることができる CwC プロパティが用意されています。詳細については、 Router / Message Processor のメッセージ サイズの上限を設定するをご覧ください。

上限

Apigee は、クライアント アプリケーションとバックエンド サーバーが、Apigee Edge の上限の Request/response size で説明されている上限を超えるペイロード サイズを送信しないことを想定しています。

  1. パブリック クラウド ユーザーの場合、リクエストとレスポンスのペイロード サイズの上限は、Apigee Edge の上限の Request/response size で説明されているとおりです。
  2. Private Cloud ユーザー の場合、リクエストとレスポンスのペイロード サイズのデフォルトの制限を変更している可能性があります（推奨される方法ではありません）。リクエスト ペイロードの最大サイズの上限は、現在の制限を確認する方法の手順に沿って確認できます。

現在の制限を確認する方法

このセクションでは、Message Processor でプロパティ HTTPRequest.body.buffer.limit が新しい値で更新されたことを確認する方法について説明します。

  1. Message Processor マシンで、/opt/apigee/edge-message- processor/conf ディレクトリのプロパティ HTTPRequest.body.buffer.limit を検索し、次のコマンドを使用して設定されている値を確認します。
    grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
  2. 上記のコマンドの出力例は次のとおりです。
    /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

  3. 上記の出力例では、http.properties の HTTPRequest.body.buffer.limit プロパティが 10m の値で設定されています。

    これは、Apigee for Private Cloud で構成されたリクエスト ペイロード サイズの制限が 10 MB であることを示しています。

Apigee サポートのサポートが必要な場合は、診断情報の収集が必要な場合をご覧ください。

診断情報の収集が必要な場合

次の診断情報を収集して、Apigee Edge サポートにお問い合わせください。

Public Cloud ユーザーの場合は、次の情報を提供してください。

  • 組織名
  • 環境名
  • API プロキシ名
  • 413 エラーを再現するために使用される完全な curl コマンド
  • API リクエストのトレース ファイル

Private Cloud ユーザーの場合は、次の情報を提供してください。

  • 失敗したリクエストで確認されたエラー メッセージの全文
  • 組織名
  • 環境名
  • API プロキシ バンドル
  • 失敗した API リクエストのトレース ファイル
  • 413 エラーを再現するために使用される完全な curl コマンド

  • NGINX アクセスログ /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    説明: ORG、ENV、PORT# は実際の値に置き換えます。

  • Message Processor のシステムログ /opt/apigee/var/log/edge-message-processor/logs/system.log