本頁面由 Cloud Translation API 翻譯而成。

400 Bad Request - DecompressionFailureAtRequest

查看 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 中指定的編碼為有效且目前由 Apigee Edge 支援

但是

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

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

注意：Content-Encoding 標頭代表標籤是否屬於傳送方和接收方的訊息酬載。一般而言這是指用來壓縮酬載的壓縮類型。如要進一步瞭解 Apigee Edge 支援的編碼格式，請參閱支援的編碼。

以下列舉幾個支援 Content-Encoding 值和 Apigee Edge 方式的範例。在下列情況中，酬載格式應是：

情境 Content-Encoding 預期酬載格式

單一編碼

gzip

情境	Content-Encoding	預期酬載格式
單一編碼	gzip	Unix `gzip` 格式。詳情請見 RFC1952 GZIP 格式。
單一編碼	延遲	這種格式使用 `zlib` 結構搭配延遲壓縮演算法。詳情請參閱 RFC1950 和 RFC1951`.`
多重編碼	多重編碼例如，若編碼作業完成兩次，則可能出現以下情形： gzip, deflate gzip、gzip deflate、gzip deflate, deflate	多重編碼會依照標頭中的特定順序套用於酬載。

Unix gzip 格式。

詳情請見 RFC1952 GZIP 格式。

單一編碼

延遲

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

詳情請參閱 RFC1950 和 RFC1951.

多重編碼

例如，若編碼作業完成兩次，則可能出現以下情形：

gzip, deflate
gzip、gzip
deflate、gzip
deflate, deflate

多重編碼會依照標頭中的特定順序套用於酬載。

造成這項錯誤的可能原因如下：

原因	說明	適用的疑難排解操作說明
要求的酬載格式與 Content-Encoding 標頭中指定的編碼不符	用戶端傳送的要求酬載格式未編碼或未編碼與 `Content-Encoding` 標頭中指定的編碼相符。	邊緣公有雲和私有雲使用者

常見的診斷步驟

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

API Monitoring

如何使用 API Monitoring 診斷錯誤：

以下列使用者身分登入 Apigee Edge UI：擔任適當角色
切換到您要調查問題的機構。
前往「Analyze」(分析) >「API 監控 >調查頁面。
請選取您發現錯誤的確切時間範圍。
確認「Proxy」篩選器已設為「All」。
根據「時間」繪製「Fault Code」指標。
選取含有錯誤程式碼 messaging.adaptors.http.flow.DecompressionFailureAtRequest 的儲存格如下所示：

( 查看較大的圖片)
錯誤程式碼相關資訊 messaging.adaptors.http.flow.DecompressionFailureAtRequest 顯示如下：

( 查看較大的圖片)
按一下「查看記錄」，然後展開出現 400 錯誤的資料列。

( 查看較大的圖片)
在「Logs」(記錄檔) 視窗中，記下下列詳細資料：
- 狀態碼： 400
- 錯誤來源： proxy
- 錯誤代碼： messaging.adaptors.http.flow.DecompressionFailureAtRequest。
如果「Fault Source」的值為 proxy，則代表請求酬載格式與 Content-Encoding 標頭中指定的支援編碼。

追蹤工具

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

啟用追蹤工作階段和下列其中一項：
1. 等待 400 Bad Request 錯誤發生，或
2. 如果可以重現問題，請發出 API 呼叫並重現問題 400 Bad Request。
確保已啟用「Show all FlowInfos」：
請選取其中一個失敗的要求，然後檢查追蹤記錄。
瀏覽追蹤記錄的各個階段，找出失敗之處發生。
一般而言，您通常會在 從用戶端收到的要求階段，如下所示：

( 查看較大的圖片)
請注意追蹤記錄中的屬性值：
- 錯誤： 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 標頭中指定的格式相同
請判斷要求標頭 Content-Encoding 的值。這時請前往「Request Received from Client」階段，如下所示：

( 查看較大的圖片)

請注意，要求標頭 Content-Encoding 的值確實是 gzip。

上述追蹤記錄範例顯示要求標頭中指定的編碼方式 Content-Encoding為 gzip；不過，請求酬載不是 GZIP 格式。因此 Apigee 無法使用 gzip 並傳回 Decompression failure at request 錯誤。
請前往以下畫面，記下 Apigee Edge 傳回的狀態碼和錯誤訊息
追蹤記錄中的「Response Sent to Client」(回應傳送至用戶端) 階段，如下所示：

( 查看較大的圖片)

請注意下列追蹤記錄詳細資料：
- 狀態碼： 400 Bad Request。
- 錯誤內容： {"fault":{"faultstring":"Decompression failure at request","detail":{"errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"}}}
前往追蹤記錄中的「AX」AX(已記錄的 Analytics 資料) 階段然後按一下
向下捲動至「Phase Details」、「Error Headers」部分，然後確定 X-Apigee-fault-code 和 X-Apigee-fault-source 的值如下所示：
( 查看較大的圖片)

您會看到 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 存取記錄診斷錯誤：

如果您是 Private Cloud 使用者，可以使用 NGINX 存取記錄來判斷 HTTP 400 錯誤的相關重要資訊。
查看 NGINX 存取記錄：

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

其中： ORG、ENV 和 PORT# 會替換為實際值。
搜尋，查看在特定期間是否有任何 400 錯誤 (如果問題是過去發生) 或者 400。

如果發現任何含有 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`

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

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

診斷

針對使用 API 觀察到的錯誤判斷「錯誤程式碼」和「錯誤來源」 Monitoring、Trace 工具或 NGINX 存取記錄常見的診斷步驟。
如果「Fault Code」顯示為 messaging.adaptors.http.flow.DecompressionFailureAtRequest和「Fault Source」具有 policy 或 proxy 值，那麼這個表示用戶端應用程式傳送的要求含有與要求標頭 Content-Encoding 中指定的支援編碼。
如要判斷 HTTP 要求中的不相符情形，請使用以下其中一種程式碼方法：
錯誤訊息

如何使用錯誤訊息進行驗證：
1. 如果您可以存取 Apigee Edge 收到的完整錯誤訊息，請參閱 faultstring。
  
  錯誤訊息示例：
```
"faultstring":"Decompression failure at request"
```
2. 在上述錯誤訊息中 "Decompression failure at request"，表示要求無法使用 Content-Encoding 標頭。
Trace

如何使用 Trace 進行驗證：
1. 判斷要求標頭 Content-Encoding 的值和使用 Trace 屬性 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 標頭支援的編碼方式。不過，「要求酬載」「request_payload.zip」為 ZIP 格式。因此這個請求失敗，並顯示 400 Bad Request 狀態碼和錯誤代碼： messaging.adaptors.http.flow.DecompressionFailureAtRequest。
訊息處理器記錄

注意：本節的操作說明僅適用於 Edge Private Cloud 使用者。

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

如果您是 Private Cloud 使用者，可以使用訊息處理者記錄檔來判斷 HTTP 400 錯誤的相關重要資訊。
1. 利用 API 監控、追蹤工具、追蹤工具或 NGINX 存取記錄 (方法請見常見診斷步驟)。
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因此，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 ，表示在定義格式，且與 Content-Encoding 標頭已延後。因此，Apigee Edge 擲回例外狀況並傳回 400 狀態碼，包括錯誤代碼 messaging.adaptors.http.flow.DecompressionFailureAtRequest 。

解析度

如果在 Apigee Edge 的 API Proxy 流程中不需要使用壓縮要求酬載在後端伺服器中，則「不要」傳遞標頭 Content-Encoding。如果需要壓縮要求酬載，請跳至步驟 2。
確認用戶端應用程式一律傳送下列內容：
- 任何支援的編碼是Content-Encoding 要求
- Apigee Edge 支援格式的要求酬載與編碼相符 Content-Encoding 標頭中指定的格式
在上例中，要求酬載採用 ZIP 格式，但要求標頭會指定 Content-Encoding: gzip。如要修正問題，請傳送要求 Content-Encoding: gzip 做為標頭，而要求酬載也是 gzip 格式：
```
curl -v "https://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.gz
```
注意：如果在 Content-Encoding 標頭中指定多個值，則確保對酬載套用多個編碼的順序與出現的順序相同。

規格

Apigee Edge 會以狀態碼 400 Bad Request 回應根據下列 RFC 定義 messaging.adaptors.http.flow.DecompressionFailureAtRequest 規格：

規格
RFC 7231，6.5.1 節
RFC 7231，3.1.2.2 節

如果仍需 Apigee 支援團隊的協助，請前往必須收集診斷資訊。

必須收集診斷資訊

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

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

機構名稱
環境名稱
API Proxy 名稱
完成 curl 指令 (用來重現 400 錯誤)
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

400 Bad Request - DecompressionFailureAtRequest

問題

錯誤訊息

可能原因

常見的診斷步驟

API Monitoring

追蹤工具

NGINX

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

診斷

錯誤訊息

Trace

實際要求

訊息處理器記錄

情境 1

情境 2

解析度

規格

必須收集診斷資訊

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