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

現在、Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントをご確認ください。 情報

内容

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

エラー メッセージ

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

HTTP/1.1 413 Request Entity Too Large

また、次のエラー メッセージが表示される場合があります。 

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

考えられる原因

このエラーは、HTTP リクエストの一部としてクライアント アプリケーションから Apigee Edge に送信されたペイロード サイズが、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. [Time] に [Fault Code] をプロットします。

  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 による非圧縮の場合は許容上限よりも大きいことを示します。

Trace

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

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

  2. [Show all Flow Infos]（すべてのフロー情報を表示）が有効になっていることを確認します。

  3. 失敗したリクエストの 1 つを選択し、トレースを調べます。
  4. 「Request Received from Client」（クライアントからのリクエストの受信）フェーズに進みます。

    非圧縮

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

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

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

    圧縮

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

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

    • Content-Encoding: gzip
    • Content-Length: 14969
    • コンテンツ タイプ: 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. 次の表に、2 つのシナリオで client.received.content.length 変数の値に基づいて 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 が X-Apigee-fault-code の値と一致する 413 エラーが見つかった場合は、X-Apigee-fault-code の値を確認します。

    非圧縮

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

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

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

    [Request Length:] は 15360440（14.6 MB > 上限以下）であることにご注意ください。

    圧縮

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

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

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

    [Request Length:] は 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 を超えていることを検出すると、その後の解凍を停止し、すぐに 413 Request Entity Too Large でエラーコード protocol.http.TooBigBody を返します。

診断

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

    Trace

    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 を超えるペイロードの場合、Apigee JavaCallout 内で署名付き URL パターンを使用することをおすすめします（GitHub の Edge Callout: 署名付き URL 生成ツールの例を参照）。

ストリーミング

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

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

CwC

方法 4 : CwC プロパティを使用してバッファ上限を増やす

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

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

上限

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

  1. Public Cloud ユーザーの場合、リクエストとレスポンスのペイロード サイズの上限は、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. 上の出力例では、プロパティ HTTPRequest.body.buffer.limit が http.properties の値 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