400 Bad Request - DecompressionFailureAtRequest

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

症状

クライアント アプリケーションが HTTP ステータス コードと 400 Bad Request エラーコードを取得する messaging.adaptors.http.flow.DecompressionFailureAtRequest （API へのレスポンス） できます。

エラー メッセージ

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

HTTP/1.1 400 Bad Request

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

{
   "fault":{
      "faultstring":"Decompression failure at request",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"
      }
   }
}

考えられる原因

このエラーは、次の場合にのみ発生します。

  • HTTP リクエスト ヘッダー Content-Encoding で指定されたエンコード 有効であり、 <ph type="x-smartling-placeholder"></ph> Apigee Edge でサポートされている

    • ただし

  • HTTP リクエストの一部としてクライアントによって送信されるペイロード形式は、 Content-Encoding ヘッダーで指定されたエンコード形式と一致している

これは Apigee Edge が、指定されたエンコードを使用したペイロードのデコードに失敗するためです。これは、 ペイロードの形式が、 Content-Encoding ヘッダー。

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

サポートされている Content-Encoding値の例と Apigee Edge が、 では、次の場合のペイロード形式が想定されます。

シナリオ Content-Encoding 想定されるペイロード形式
単一エンコード gzip

Unix gzip 形式。

詳しくは、 <ph type="x-smartling-placeholder"></ph> RFC1952 GZIP 形式。

単一エンコード Deflate

この形式は、deflate 圧縮アルゴリズムを使用した zlib 構造を使用します。

<ph type="x-smartling-placeholder"></ph>をご覧ください。 RFC1950 および <ph type="x-smartling-placeholder"></ph> RFC1951.
複数のエンコード

複数のエンコード

たとえば、エンコードが 2 回行われる場合は、次のようになります。

  • gzip、deflate
  • gzip、gzip
  • deflate、gzip
  • deflate、deflate
 ヘッダーに記述されている順序に従って、ペイロードに複数のエンコードが適用されます。

このエラーには、次の原因が考えられます。

原因 説明 トラブルシューティングの実施対象
<ph type="x-smartling-placeholder"></ph> リクエストのペイロードの形式が、Content-Encoding ヘッダーで指定されたエンコードと一致しません クライアントから送信されたリクエスト ペイロードの形式がエンコードされていないか、エンコードされていません。 Content-Encoding ヘッダーで指定されたエンコードと一致している。 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. [プロキシ] フィルタが [すべて] に設定されていることを確認します。
  6. 障害コードを Time に対してプロットします。

  7. 障害コード messaging.adaptors.http.flow.DecompressionFailureAtRequest を持つセルを選択します。 下に示します。

    ( 拡大画像を表示）

  8. 障害コードに関する情報 messaging.adaptors.http.flow.DecompressionFailureAtRequest は次のように表示されます。

    ( 拡大画像を表示）

  9. [ログを表示] をクリックし、400 エラーで失敗した行を開きます。

    ( 拡大画像を表示）

  10. [ログ] ウィンドウで、次の詳細をメモします。 <ph type="x-smartling-placeholder">
      </ph>
    • ステータス コード: 400
    • 障害の発生元: proxy
    • 障害コード: messaging.adaptors.http.flow.DecompressionFailureAtRequest
  11. [Fault Source] の値が proxy の場合、 リクエストのペイロード形式が <ph type="x-smartling-placeholder"></ph> Content-Encoding ヘッダーで指定されたサポートされているエンコード。

Trace ツール

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

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

  1. トレース セッションを有効にする および次のいずれかです。 <ph type="x-smartling-placeholder">
      </ph>
    1. 400 Bad Request エラーが発生するのを待つ。または
    2. 問題を再現できる場合は、API 呼び出しを行い、 400 Bad Request。

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

  3. 失敗したリクエストのいずれかを選択し、トレースを調べます。
  4. トレースのさまざまなフェーズを順に確認し、障害が発生している場所を特定する 発生しました。

  5. 通常、エラーは 「Request Received from Client」フェーズを以下に示します。

    ( 拡大画像を表示）

  6. トレースのプロパティの値をメモします。

    • エラー: Decompression failure at request
    • error.class: com.apigee.rest.framework.BadRequestException
    • error.cause: Not in GZIP format

    error.cause は、リクエストのペイロードが GZIP 形式ではないことを示しています。 これは、Apigee Edge がリクエスト ペイロードが GZIP 形式であると想定していたことを意味します。 Content-Encoding ヘッダーで指定されているとおりに作成されます。

  7. リクエスト ヘッダー Content-Encoding の値を確認します。 そのためには、以下に示すように [Request Received from Client] フェーズに移動します。

    ( 拡大画像を表示）

    リクエスト ヘッダー Content-Encoding の値が実際に gzip。

    上記のサンプル トレースは、リクエスト ヘッダーで指定されたエンコードが Content-Encoding は gzip です。ただし、リクエスト ペイロードは GZIP 形式ではありません。そのため、Apigee は gzip し、エラー Decompression failure at request を返します。

  8. 次に移動して、Apigee Edge から返されたステータス コードとエラー メッセージをメモします。

    以下に示すように、トレースの Response Sent to Client フェーズにレスポンスを送信

    ( 拡大画像を表示）

    トレースの次の詳細に注意してください。

    • ステータス コード: 400 Bad Request。
    • エラーの内容: {"fault":{"faultstring":"Decompression failure at request","detail":{"errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"}}}

  9. トレースの AXAX（Analytics Data Recorded）フェーズに移動します。 クリックします。

  10. [Phase Details]、[Error Headers] セクションまで下にスクロールし、 X-Apigee-fault-codeX-Apigee-fault-code と X-Apigee-fault-sourceX-Apigee-fault-code の値を確認します。 次のように指定します。

    ( 拡大画像を表示）

  11. X-Apigee-fault-code と X-Apigee-fault-source の値が表示されます。 messaging.adaptors.http.flow.DecompressionFailureAtRequest として、および policy は、リクエストのペイロード形式が Content-Encoding ヘッダーで指定されたエンコード。
    レスポンス ヘッダー 値
    X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtRequest
    X-Apigee-fault-source policy

NGINX

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

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

  1. Private Cloud ユーザーは、NGINX アクセスログを使用して次のことを行えます。 HTTP 400 エラーに関する重要な情報を確認する。

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

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

    ここで、 ORG、ENV、PORT# は実際の値に置き換えられます。

  3. 特定の期間に 400 エラーがないか検索して確認できます （過去に発生した場合）か、引き続き失敗するリクエストがあるかどうかを 400。

  4. X-Apigee-fault-code で 400 エラーが見つかった場合 値 messaging.adaptors.http.flow.DecompressionFailureAtRequest と一致し、 次に、X-Apigee-fault-source. の値を確認します。

    NGINX アクセスログの 400 エラーの例:

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

    レスポンス ヘッダー 値
    X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtRequest
    X-Apigee-fault-source policy

原因: リクエストのペイロード形式が、指定されたエンコードと一致していない Content-Encoding ヘッダー内

デフォルトでは、Apigee Edge はリクエスト ヘッダーに Content-Encoding には、有効なフィールドと <ph type="x-smartling-placeholder"></ph> エンコード方式をご覧ください。そのため、リクエスト ペイロードの形式は リクエスト ヘッダー Content-Encoding で指定されたエンコードと一致する必要があります。 不一致がある場合は、このエラーが発生します。

診断

  1. API を使用して、観測されたエラーの障害コードと障害ソースを特定します。 Monitoring、Trace ツール、または NGINX アクセスログ（ 一般的な診断手順。
  2. 障害コードが messaging.adaptors.http.flow.DecompressionFailureAtRequest および [Fault Source] の値が policy または proxy の場合、 は、クライアント アプリケーションから送信されたリクエストのペイロードが サポートされているエンコードがリクエスト ヘッダー Content-Encoding で指定されます。

  3. 次のいずれかの方法で、HTTP リクエストの一部として不一致を判断できます。 メソッド:

    エラー メッセージ

    エラー メッセージを使用して検証するには:

    1. Apigee Edge から受信した完全なエラー メッセージにアクセスできる場合は、 faultstring をご覧ください。

      エラー メッセージの例:

      "faultstring":"Decompression failure at request"
    2. 上記のエラー メッセージでは、 "Decompression failure at request"。これは、リクエストが 指定されたエンコードで圧縮解除できませんでした。 Content-Encoding ヘッダー。

    トレース

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

    1. リクエスト ヘッダー Content-Encoding の値と、 Trace を使用した error.cause プロパティ 一般的な診断手順で説明されているとおりに処理されます。

    2. サンプル トレースの値は次のとおりです。

      • Content-Encoding: gzip
      • error.cause: Not in GZIP format

      リクエスト ヘッダー Content-Encoding の値は gzip です。 ただし、リクエストのペイロードが GZIP 形式でない （error.cause で示されます）。したがって、Apigee Edge は 400 Bad Request とエラーコード messaging.adaptors.http.flow.DecompressionFailureAtRequest。

    実際のリクエスト

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

    クライアントからの実際のリクエストにアクセスできる場合 次の手順を実施します

    1. リクエスト ヘッダー Content-Encoding に渡される値を確認します。
    2. リクエストの一部として送信されるペイロードの形式を特定します。

    3. Content-Encoding ヘッダーの値が次のリストにある場合: <ph type="x-smartling-placeholder"></ph> サポートされているエンコードですが、リクエスト ペイロードの形式は Content-Encoding ヘッダーで指定されたエンコードと一致している。 それが問題の原因です

      リクエストの例:

      curl -v "http://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.zip

      上記のサンプル リクエストでは、値 gzip が Content-Encoding ヘッダーは、 <ph type="x-smartling-placeholder"></ph> サポートされているエンコードをご確認ください。ただし、リクエスト ペイロードは request_payload.zip は ZIP 形式です。そのためこのリクエストは 400 Bad Request ステータス コードとエラーコードで失敗します。 messaging.adaptors.http.flow.DecompressionFailureAtRequest。

    Message Processor のログ

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

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

    Private Cloud ユーザーは、Message Processor のログを使用できます。 HTTP 400 エラーに関する重要な情報を確認します。

    1. 失敗したリクエストのメッセージ ID を、API Monitoring、Trace ツール、 または NGINX アクセスログを作成する必要があります。詳しくは、一般的な診断手順をご覧ください。

    2. Message Processor ログでメッセージ ID を検索します。

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

    3. 次のいずれかの例外が表示されます。

      シナリオ #1

      シナリオ #1: API リクエストにヘッダー Content-Encoding: gzip がある場合

      2021-07-28 10:21:16,861  NIOThread@0 ERROR HTTP.SERVER -
HTTPServer$Context.onInputException() : Message id:rt-57-1
SSLClientChannel[Accepted: Remote:192.168.199.8:8443
Local:192.168.80.234:44284]@28469 useCount=1 bytesRead=0
bytesWritten=28764 age=2739893ms  lastIO=0ms
isOpen=true.onExceptionRead exception: {}
java.util.zip.ZipException: Not in GZIP format

2021-07-28 10:21:16,862  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW -
AbstractRequestListener.onException() : Request:POST, uri:/test,
message Id:rt-57-1, exception:java.util.zip.ZipException: Not in GZIP format,
context:Context@71ea5ac input=ClientInputChannel(SSLClientChannel[Accepted:
Remote:192.168.199.8:8443 Local:192.168.80.234:44284]@28469 useCount=1
bytesRead=0 bytesWritten=28764 age=2739894ms  lastIO=0ms  isOpen=true)
2021-07-28 10:21:16,862  NIOThread@0 INFO  HTTP.SERVICE -
ExceptionHandler.handleException() :
Exception java.util.zip.ZipException: Not in GZIP format occurred while writing
to channel null
2021-07-28 10:21:16,863  NIOThread@0 INFO  HTTP.SERVICE -
ExceptionHandler.handleException() : Exception trace:
java.util.zip.ZipException: Not in GZIP format

      上記のエラー メッセージの java.util.zip.ZipException: Not in GZIP format 行目は、リクエストが ペイロードは GZIP 形式で送信されませんが、Content-Encoding gzip として指定されます。Apigee Edge は例外をスローし、 400 ステータス コードと障害コードを返す messaging.adaptors.http.flow.DecompressionFailureAtRequest クライアントアプリケーションに提供します

      シナリオ #2

      シナリオ #2: API リクエストに Content-Encoding: deflate ヘッダーがある場合

      2021-07-28 15:26:31,893  NIOThread@1 ERROR HTTP.SERVER -
HTTPServer$Context.onInputException() : Message id:rt-47875-1
SSLClientChannel[Accepted: Remote:192.168.199.8:8443
Local:192.168.81.72:45954]@29276 useCount=1 bytesRead=0
bytesWritten=37230 age=3498856ms  lastIO=1ms
isOpen=true.onExceptionRead exception: {}
java.util.zip.ZipException: incorrect header check
                  ….
Caused by: java.util.zip.DataFormatException: incorrect header check
       ..
2021-07-28 15:26:31,894  NIOThread@1 ERROR ADAPTORS.HTTP.FLOW -
AbstractRequestListener.onException() : Request:POST, uri:/test,
message Id:rrt-47875-1, exception:java.util.zip.ZipException:
incorrect header check, context:Context@69b3ac45
input=ClientInputChannel(SSLClientChannel[Accepted:
Remote:192.168.199.8:8443 Local:192.168.81.72:45954]@29276
useCount=1 byt	esRead=0 bytesWritten=37230 age=3498856ms
lastIO=1ms  isOpen=true)

      行 java.util.zip.ZipException: incorrect header check および Caused by: java.util.zip.DataFormatException: incorrect header check 上記のエラー メッセージを見ると、リクエストのペイロードが deflate 形式であり、 deflate の Content-Encoding ヘッダー。Apigee Edge は 例外がスローされ、次を含む 400 ステータス コードが返されます。 障害コード messaging.adaptors.http.flow.DecompressionFailureAtRequest クライアントアプリケーションに提供します

解決策

  1. Apigee Edge の API プロキシフローで圧縮リクエスト ペイロードが必要ない場合 バックエンド サーバーでは、ヘッダー Content-Encoding を渡さないでください。 リクエスト ペイロードを圧縮する必要がある場合は、ステップ 2 に進みます。
  2. クライアント アプリケーションが常に以下を送信するようにします。 <ph type="x-smartling-placeholder">
      </ph>
    • 次のいずれか <ph type="x-smartling-placeholder"></ph> サポートされているエンコードを Content-Encoding ヘッダーの値として リクエスト
    • Apigee Edge へのサポートされている形式のリクエスト ペイロードがエンコードと一致している Content-Encoding ヘッダーで指定された形式
  3. 上記の例では、リクエストのペイロードは ZIP 形式ですが、リクエスト ヘッダーは Content-Encoding: gzip を指定します。この問題を解決するには、 ヘッダーを Content-Encoding: gzip として指定し、リクエスト ペイロードも gzip に含めます。 形式: 
    curl -v "https://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.gz
    <ph type="x-smartling-placeholder">

仕様

Apigee Edge は、ステータス コード 400 Bad Request とエラーコードを返します。 次の RFC に基づく messaging.adaptors.http.flow.DecompressionFailureAtRequest 仕様:

仕様
<ph type="x-smartling-placeholder"></ph> RFC 7231、セクション 6.5.1
<ph type="x-smartling-placeholder"></ph> RFC 7231、セクション 3.1.2.2

Apigee サポートのサポートが必要な場合は、にアクセスしてください。 診断情報の収集が必要な場合。

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

次の診断情報を収集して、Apigee Edge サポートに連絡してください。

Public Cloud ユーザーの場合は、次の情報を提供します。

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

Private Cloud ユーザーの場合は、次の情報を提供します。

  • 失敗したリクエストについて観測された完全なエラー メッセージ
  • 環境名
  • API プロキシ バンドル
  • API リクエストのトレース ファイル

  • 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