502 閘道錯誤 - ResponseWithBody

您目前查看的是 Apigee Edge 說明文件。
前往 Apigee X 說明文件。 info

問題

用戶端應用程式會收到 HTTP 狀態碼 502 Bad Gateway，以及錯誤代碼 protocol.http.ResponseWithBody，做為 API 呼叫的回應。

錯誤訊息

用戶端應用程式會取得下列回應代碼：

HTTP/1.1 502 Bad Gateway

此外，您可能會看到下列其中一則錯誤訊息：

{
   "fault":{
      "faultstring":"Received 204 Response with message body",
      "detail":{
         "errorcode":"protocol.http.ResponseWithBody"
      }
   }
}

{
   "fault":{
      "faultstring":"Received 205 Response with message body",
      "detail":{
         "errorcode":"protocol.http.ResponseWithBody"
      }
   }
}

可能原因

如果後端伺服器傳送給 Apigee Edge 的 HTTP 回應是 204 No Content 或 205 Reset Content，但包含回應主體和/或下列一或多個標頭，就會發生這項錯誤：

• Content-Length
• Content-Encoding
• Transfer-Encoding

根據規格 RFC 7231 第 6.3.5 節：204 No Content 和 RFC 7231 第 6.3.6 節：205 Reset Content，原始伺服器不應在回應酬載主體中傳送任何額外內容，並使用狀態碼 204 No Content 或 205 Reset Content。回應標頭 (例如 Content-Length、Content-Encoding 或 Transfer-Encoding) 會指出回應酬載的大小、類型或格式。

因此，在下列情況下，Apigee Edge 會向用戶端傳回 502 Bad Gateway 狀態碼和錯誤碼 protocol.http.ResponseWithBody：

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

常見的診斷步驟

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

原因：後端伺服器傳回的回應主體或標頭含有 204 回應

診斷

1. 使用 API 監控、追蹤工具或 NGINX 存取記錄，判斷所觀察到的錯誤的錯誤代碼和錯誤來源，如常見診斷步驟所述。
2. 如果「Fault Code」為 protocol.http.ResponseWithBody，且「Fault Source」的值為 target，表示後端伺服器已傳回 204 No Content 或 205 Reset Content 狀態碼，並包含回應主體和/或「可能原因」中提及的其中一個標頭。

3. 如要驗證後端伺服器是否確實傳送回應酬載主體和/或「可能原因」中提及的一或多個標頭，請按照下列步驟操作：

   1. 如果您是公有雲使用者，且可以從任何系統直接向後端伺服器發出相同的 API 要求。

   2. 如果您是私有雲使用者，則可直接從與特定機構和環境相關聯的其中一個訊息處理器，向後端伺服器發出相同的 API 要求，藉此觀察失敗情形。

   3. 查看後端伺服器傳回的回應，確認其中包含回應酬載主體和/或上述一或多個標頭。如果是，這就是造成錯誤的原因。

      範例 #1

      範例 1：後端伺服器回應 204，並提供 Content-Encoding 標頭

      curl -v "https://BACKEND_SERVER_HOST_NAME/PATH" -H "HEADER: VALUE" -X HTTP_REQUEST_METHOD
      

      …
      < HTTP/1.1 204 No Content
      < Content-Encoding: gzip
      < Date: Tue, 31 Jul 2021 21:41:13 GMT
      < Connection: keep-alive
      

      在本範例中，後端伺服器傳回 204 No Content 狀態碼和 Content-Encoding: gzip。

      範例 #2

      範例 2：後端伺服器回應 204，並提供 Content-Length 標頭

      curl -v "https://BACKEND_SERVER_HOST_NAME/PATH" -H "HEADER: VALUE" -X HTTP_REQUEST_METHOD
      

      …
      < HTTP/1.1 204 No Content
      < Content-Length: 48
      < Date: Tue, 31 Jul 2021 21:41:13 GMT
      < Connection: keep-alive
      

      在本範例中，後端伺服器傳回 204 No Content 狀態碼和 Content-Length: 48。

      範例 #3

      範例 3：後端伺服器回應 205，並提供回應主體

      curl -v "https://BACKEND_SERVER_HOST_NAME/PATH" -H "HEADER: VALUE" -X HTTP_REQUEST_METHOD
      

      …
      < HTTP/1.1 205 Reset Content
      < Date: Sat, 31 Jul 2021 17:14:09 GMT
      < Content-Length: 12
      < Content-Type: text/plain; charset=utf-8
      <
      * Connection #0 to host X.X.X.X left intact
      This is a sample Response
      

      在本範例中，後端伺服器傳回 205 Reset Content 狀態碼和回應主體 This is a sample Response.。

   4. 在上述所有範例中，後端伺服器傳送了 204 No Content 或 205 Reset Content 狀態碼，以及回應主體和/或「可能原因」一節中提及的其中一個標頭。
   5. 因此，Apigee Edge 會傳送 502 Bad Gateway 狀態碼和錯誤代碼 protocol.http.ResponseWithBody。

解析度

請確保後端伺服器在傳送 204 No Content 或 205 Reset Content 回應給 Apigee Edge 時，一律遵守「規格」 RFC 7231 第 6.3.6 節：205 Reset Content。也就是說，後端伺服器不得在 204 No Content 或 205 Reset Content 回應中傳送下列內容：

1. 回應酬載主體
2. 以及下列任一標頭：
   1. Content-Length
   2. Content-Encoding
   3. Transfer-Encoding

規格

如果後端伺服器傳送 204 No Content 或 205 Reset Content 回應，但未遵守下列 RFC 規格，Apigee Edge 會傳回 502 Bad Gateway 狀態碼和錯誤代碼 protocol.http.ResponseWithBody：

注意事項

建議的解決方法是修正後端伺服器，傳送 204 No Content 和 205 Reset Content 狀態碼，且不含回應主體和任何標頭 (Content-Length、Content-Encoding 和 Transfer-Encoding)，並遵守 RFC 7231 第 6.3.5 節：204 No Content 和 RFC 7231 第 6.3.6 節：205 Reset Content 的規格。

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

必須收集診斷資訊

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

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

• 機構名稱
• 環境名稱
• API Proxy 名稱
• 用於重現 502 錯誤的完整 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