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

<ph type="x-smartling-placeholder"></ph> 現在、Apigee Edge のドキュメントが表示されています。
Apigee X のドキュメント。 詳細

症状

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

エラー メッセージ

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

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 ユーザーと Edge Private Cloud ユーザー
終了後にリクエストのペイロード サイズが上限を超えた場合 解凍 HTTP の一部としてクライアント アプリケーションによって圧縮形式で送信されたペイロード サイズ Apigee Edge への解凍時に許容される上限を超えています。 Edge Public Cloud ユーザーと Edge Private Cloud ユーザー

共通の診断手順

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

API Monitoring

<ph type="x-smartling-placeholder">

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

  1. <ph type="x-smartling-placeholder"></ph> Apigee Edge UI にログインするユーザーとして、 付与します。

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

  3. [Analyze] >API モニタリング >Investigate ページをご覧ください。
  4. エラーが発生した期間を選択します。
  5. [Proxy] フィルタを選択して、障害コードを絞り込むことができます。
  6. 障害コードを Time に対してプロットします。

  7. 障害コードが protocol.http.TooBigBody のセルを選択し、 Status Code 413:

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

  9. [ログを表示] をクリックし、失敗したリクエストの行を開きます。次に、 [Logs] ウィンドウが表示されたら、次の詳細情報をメモします。

    非圧縮

    シナリオ #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 で圧縮されていないときのペイロード サイズが、許容される上限を超えている。

トレース

<ph type="x-smartling-placeholder">

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

  1. トレース セッションを有効にし、以下のいずれかを行います。 <ph type="x-smartling-placeholder">
      </ph>
    • 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: なし
    • コンテンツの長さ: 15360204

    圧縮

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

    次の点に注意してください。

    • Content-Encoding: gzip
    • コンテンツの長さ: 14969
    • コンテンツ タイプ: application/x-gzip
  5. トレースのさまざまなフェーズを移動して、エラーが発生した場所を特定します。

  6. このエラーは通常、[Request Received from クライアント フェーズを以下に示します。

  7. トレースのエラーの値をメモします。上記のサンプル トレースから、次のことがわかります。 <ph type="x-smartling-placeholder">
      </ph>
    • エラー: 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 の値を確認します。 <ph type="x-smartling-placeholder">
      </ph>
    • 非圧縮形式で送信された場合のリクエスト ペイロードの実際のサイズ。
    • Apigee による解凍時のリクエスト ペイロードのサイズ（ペイロードが 圧縮して送信します。この値は常に許可される 上限（10 MB）です。
    で確認できます。 <ph type="x-smartling-placeholder">

    非圧縮

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

    client.received.content.length 変数: 15360204

    圧縮

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

    client.received.content.length 変数: 10489856

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

    解凍時にサイズ上限を超過

    <ph type="x-smartling-placeholder">

NGINX

<ph type="x-smartling-placeholder">

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

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

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

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

    <ph type="x-smartling-placeholder">
  3. 特定の期間に 413 エラーがないかどうかを確認（例: 過去に発生したことがある）か、引き続き Cloud Logging によって 413。
  4. X-Apigee-fault-code が一致する 413 エラーがある場合 protocol.http.TooBigBody の値を取得してから、 X-Apigee-fault-source.

    非圧縮

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

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

    レスポンス ヘッダー 値
    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-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. [Fault Code]、[Fault Source]、[Request Payload Size] の値を確認します。 API Monitoring、Trace Tool、または NGINX アクセスログを使用して確認されたエラー シナリオ 1（非圧縮）の一般的な診断手順
  2. [Fault Source] の値が policy または proxy の場合、 クライアント アプリケーションから Apigee に送信されるリクエスト ペイロード サイズが Apigee Edge で許可されている上限。
  3. ステップ 1 で決定したリクエストのペイロード サイズを確認します。
  4. リクエスト ペイロードのサイズが本当に大きいか検証することもできます。上限 10 MB 次の手順に沿って実際のリクエストを確認します。 <ph type="x-smartling-placeholder">
      </ph>
    1. クライアント アプリケーションから行われた実際のリクエストにアクセスできない場合は、 解決策。
    2. クライアント アプリケーションから行われた実際のリクエストにアクセスできる場合は、 手順は次のとおりです。 <ph type="x-smartling-placeholder">
        </ph>
      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 未満、 <ph type="x-smartling-placeholder"></ph> 上限に到達したら、それ以上の解凍を停止して、レスポンスを返します。 413 Request Entity Too Large（エラーコードあり）で即座に protocol.http.TooBigBody。

診断

  1. 障害コード、障害ソース、リクエスト ペイロードのサイズを確認します。 API Monitoring、Trace Tool、または NGINX Access のログを使用して、 シナリオ 2（圧縮）の一般的な診断手順
  2. [Fault Source] の値が policy または proxy の場合: これは、クライアント アプリケーションから Apigee に送信されるリクエスト ペイロード サイズが大きいことを示します。 Apigee Edge で許可されている上限を超えています。
  3. ステップ 1 で特定した Request Payload Size を確認します。
    • ペイロード サイズが >上限の 10 MB である場合、これがエラーの原因です。
    • ペイロード サイズが上限が 10 MB である場合、そのリクエストは 圧縮された形式で渡されます。この場合は、Cloud Storage バケットの非圧縮サイズを 圧縮されたリクエスト ペイロードが渡されます。
  4. クライアントからのリクエストが圧縮形式で送信されたかどうかと、 次のいずれかの方法を使用して、非圧縮サイズが上限を超えています メソッド:

    トレース

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

    1. 失敗したリクエストのトレースをキャプチャした場合は、 Traceと <ph type="x-smartling-placeholder">
        </ph>
      1. client.received.content.length 変数の値を確認します。
      2. クライアントからのリクエストに Content-Encoding: gzip ヘッダー
    2. client.received.content.length 変数の値が 10 MB、 <ph type="x-smartling-placeholder"></ph> 、リクエスト ヘッダー Content-Encoding: gzip、 場合、それがこのエラーの原因です。

    実際のリクエスト

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

    1. クライアント アプリケーションから行われた実際のリクエストにアクセスできない場合は、 解決策。
    2. クライアント アプリケーションから行われた実際のリクエストにアクセスできる場合は、 手順は次のとおりです。 <ph type="x-smartling-placeholder">
        </ph>
      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 ログを使用して検証するには:

    <ph type="x-smartling-placeholder">
    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

      これは、[Request Payload Size] が 10 MB を超えていることを意味しており、Apigee がスローします。 サイズが上限の 10 MB を超え始めたときのエラー RequestTooLarge （障害コード: protocol.http.TooBigBody）

      <ph type="x-smartling-placeholder">

解決策

<ph type="x-smartling-placeholder">

サイズを修正

オプション 1 [推奨]: 上限

<ph type="x-smartling-placeholder">をご覧ください。 <ph type="x-smartling-placeholder">
    </ph>
  1. 特定のクライアントが、許容を超えるリクエスト / ペイロード サイズを送信する理由を分析する 制限で定義されているとおりです。

  2. これが望ましくない場合は、リクエスト / ペイロードを送信するようにクライアント アプリケーションを修正 サイズを小さくしてください。

    上記の例では、サイズの小さいファイルを渡して問題を解決できます。 以下に示すように、test5mbfile（サイズが 5 MB）のペイロードがあるとします。 

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
  3. 上限を超えてリクエスト/ペイロードを送信することが望ましい場合は、 選択します。

署名付き URL パターン

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

<ph type="x-smartling-placeholder">

ペイロードが 10 MB を超える場合、Apigee では、署名付き URL パターンを 図で示されている Apigee JavaCallout <ph type="x-smartling-placeholder"></ph> Edge Callout: 署名付き URL 生成ツールのサンプル（GitHub）

ストリーミング

方法 3 : ストリーミングを使用する

API プロキシで非常に大きなリクエストやレスポンスを処理する必要がある場合は、 ストリーミングをご覧ください。

<ph type="x-smartling-placeholder">

CwC

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

<ph type="x-smartling-placeholder">

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

Apigee は、 CwC プロパティ: リクエストとレスポンスのペイロード サイズの上限。詳しくは、 <ph type="x-smartling-placeholder"></ph> Router または Message Processor でメッセージ サイズの上限を設定する

<ph type="x-smartling-placeholder">

上限

Apigee では、クライアント アプリケーションとバックエンド サーバーでは、ペイロードのサイズが Request/response size の上限 Apigee Edge の制限。

  1. Public Cloud ユーザーの場合、リクエストとレスポンスの上限 ペイロード サイズは、Request/response size の Apigee Edge の制限。
  2. Private Cloud ユーザー は、デフォルトのクラウド サービス アカウントを リクエストとレスポンスのペイロード サイズに制限があります（推奨されませんが）。 リクエスト ペイロードの最大サイズの上限は、 現在の上限を確認する方法

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

<ph type="x-smartling-placeholder">

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

  1. Message Processor マシンで、次のプロパティを検索します。 /opt/apigee/edge-message- processor/conf ディレクトリ内で HTTPRequest.body.buffer.limit を実行し、次のコマンドを使用して設定されている値を確認します。 command: 
    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 の値は 10m に設定されています http.properties。

    これは、Apigee for Private で構成されたリクエスト ペイロード サイズの上限 クラウドの容量は 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