400 Bad Request - DecompressionFailureAtRequest

您正在查看 Apigee Edge 說明文件。
查看 Apigee X 說明文件。 資訊

問題

用戶端應用程式會取得 400 Bad Request 的 HTTP 狀態碼和錯誤代碼 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 中指定的編碼有效，且 Apigee Edge 支援。

    • 但是

  • 用戶端在 HTTP 要求中傳送的酬載格式，與 Content-Encoding 標頭中指定的編碼格式不符。

這是因為酬載的格式與 Content-Encoding 標頭中指定的編碼格式不同，因此 Apigee Edge 無法使用指定的編碼解碼酬載。

以下列舉幾個支援的 Content-Encoding 值，以及 Apigee Edge 預期酬載格式會是這些情況的預期方式：

情境 Content-Encoding 預期的酬載格式
單一編碼 gzip

Unix gzip 格式。

請參閱 RFC1952 GZIP 格式。
單一編碼 誹謗

這種格式使用 zlib 結構搭配延遲壓縮演算法。

詳情請參閱 RFC1950 和 RFC1951.
多個編碼

多個編碼

舉例來說，如果編碼作業兩次，以下是可能的結果：

  • gzip、deflate
  • gzip、gzip
  • deflate, gzip
  • 延遲, 降低
 依照標頭中顯示的指定順序，套用至酬載的多種編碼。

此錯誤的可能原因如下：

原因 說明 適用的疑難排解指示
要求酬載格式與 Content-Encoding 標頭中指定的編碼不符 用戶端傳送的要求酬載格式未編碼，或是與 Content-Encoding 標頭中指定的編碼不符。 Edge Public and Private Cloud 使用者

常見診斷步驟

請使用下列其中一種工具/技巧診斷這項錯誤：

API Monitoring

如何使用 API Monitoring 診斷錯誤：

  1. 以 適當角色的使用者 登入 Apigee Edge UI。

  2. 切換至您想要調查問題的機構。

  3. 前往「分析」>「API 監控」>「調查」頁面。
  4. 請選取你發現錯誤的特定時間範圍。
  5. 確認「Proxy」篩選器已設為「全部」。
  6. 將「Fault Code」與「Time」進行比較。

  7. 選取含有錯誤代碼 messaging.adaptors.http.flow.DecompressionFailureAtRequest 的儲存格，如下所示：

    ( 查看較大圖片)。

  8. 錯誤代碼 messaging.adaptors.http.flow.DecompressionFailureAtRequest 的相關資訊如下所示：

    ( 查看較大圖片)。

  9. 按一下「查看記錄」，然後展開出現 400 錯誤失敗的資料列。

    ( 查看較大圖片)。

  10. 在「記錄檔」視窗中記下下列詳細資料：
    • 狀態碼： 400
    • Fault 資料來源： proxy
    • 錯誤代碼： messaging.adaptors.http.flow.DecompressionFailureAtRequest。
  11. 如果「Fault Source」的值為 proxy，表示要求酬載格式與 Content-Encoding 標頭中指定的 支援的編碼不符。

追蹤工具

如何使用追蹤工具診斷錯誤：

  1. 啟用追蹤工作階段，然後採取下列其中一種做法：
    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 傳回的狀態碼和錯誤訊息，請前往

    到「回應已傳送給用戶端」階段，如下所示：

    ( 查看較大圖片)。

    記下追蹤記錄中的下列詳細資料：

    • 狀態碼： 400 Bad Request。
    • 錯誤內容： {"fault":{"faultstring":"Decompression failure at request","detail":{"errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"}}}

  9. 前往追蹤記錄中的「AX」(Analytics (分析) 資料記錄) 階段，然後按一下該階段。

  10. 向下捲動至「階段詳細資料」、「錯誤標頭」區段，確定 X-Apigee-fault-code 和 X-Apigee-fault-source 的值，如下所示：

    ( 查看較大圖片)。

  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

如何使用 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 中發現符合 messaging.adaptors.http.flow.DecompressionFailureAtRequest 值的任何 400 錯誤，請找出 X-Apigee-fault-source 的值。

    NGINX 存取記錄中的 400 錯誤範例：

    以上 NGINX 存取記錄中的範例項目，有下列「X-Apigee-fault-code」X-Apigee-fault-code 和「X-Apigee-fault-source」X-Apigee-fault-code 的值：

    回應標頭 值
    X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtRequest
    X-Apigee-fault-source policy

原因：要求酬載格式與 Content-Encoding 標頭中指定的編碼不符

根據預設，如果要求標頭 Content-Encoding 包含有效且 支援的編碼，Apigee Edge 一律會解壓縮酬載。因此，要求酬載的格式應符合要求標頭 Content-Encoding 中指定的編碼。如果出現不相符的情形，就會收到這則錯誤訊息。

診斷

  1. 使用 API 監控、追蹤工具或 NGINX 存取記錄檔，按照常見診斷步驟說明，找出錯誤的「Fault Code」和「Fault Source」。
  2. 如果「Fault Code」為 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. 按照常見診斷步驟的說明，使用 Trace 判定要求標頭 Content-Encoding 和 error.cause 屬性的值，

    2. 範例追蹤記錄中的值如下：

      • 內容編碼： 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 標頭的值在 支援的編碼清單中，但要求酬載的格式與 Content-Encoding 標頭中指定的編碼不符，這就是問題原因。

      要求示例：

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

      上述要求範例將 gzip 值傳送至 Content-Encoding 標頭，這是 Apigee Edge 中 支援的編碼。不過，要求酬載 request_payload.zip 為 ZIP 格式。因此，這項要求會失敗，並出現 400 Bad Request 狀態碼和錯誤代碼：messaging.adaptors.http.flow.DecompressionFailureAtRequest。

    訊息處理器記錄

    如何使用訊息處理器記錄進行驗證：

    如果您是私人 Cloud 使用者，則可以使用訊息處理器記錄檔來判斷 HTTP 400 錯誤的相關重要資訊。

    1. 依據常見診斷步驟的說明，使用 API 監控、追蹤工具或 NGINX 存取記錄檔判斷失敗要求的訊息 ID。

    2. 在郵件處理器記錄中搜尋郵件 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 表示雖然 Content-Encoding 指定為 gzip，但要求酬載不會以 GZIP 格式傳送。因此，Apigee Edge 會擲回例外狀況，將含有錯誤代碼 messaging.adaptors.http.flow.DecompressionFailureAtRequest 的 400 狀態碼傳回用戶端應用程式。

      情境 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 行指出要求酬載並非以延遲格式傳送，且與定義 Content-Encoding 標頭中指定的編碼不符。因此，Apigee Edge 會擲回例外狀況，將含有錯誤代碼 messaging.adaptors.http.flow.DecompressionFailureAtRequest 的 400 狀態碼傳回用戶端應用程式。

解析度

  1. 如果 Apigee Edge 和後端伺服器中的 API Proxy 流程中不需要經過壓縮的要求酬載，請「不要」傳送標頭 Content-Encoding。如果您需要壓縮要求酬載，請前往步驟 2。
  2. 確保用戶端應用程式一律會傳送以下項目：
    • 要求中 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

規格

根據以下 RFC 規格，Apigee Edge 以狀態碼 400 Bad Request 回應，錯誤代碼為 messaging.adaptors.http.flow.DecompressionFailureAtRequest：

規格
RFC 7231 第 6.5.1 節
RFC 7231 第 3.1.2.2 節

如果仍需要 Apigee 支援團隊的任何協助，請參閱「 必須收集診斷資訊」。

必須收集診斷資訊

收集下列診斷資訊，然後與 Apigee Edge 支援團隊聯絡：

如果您是公開雲端使用者，請提供下列資訊：

  • 機構組織名稱
  • 環境名稱
  • API Proxy 名稱
  • 完成用來重現 400 錯誤的 curl 指令
  • API 要求的追蹤檔

如果您是 Private Cloud 使用者，請提供下列資訊：

  • 觀察失敗要求的完整錯誤訊息
  • 環境名稱
  • API Proxy 套裝組合
  • API 要求的追蹤檔

  • NGINX 存取記錄檔 /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    其中：系統會將 ORG、ENV 和 PORT# 替換為實際值。

  • 訊息處理器系統記錄 /opt/apigee/var/log/edge-message-processor/logs/system.log