502 閘道錯誤 - ResponseWithBody

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

問題

用戶端應用程式會取得 502 Bad Gateway 的 HTTP 狀態碼，以及錯誤代碼 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 無內容和 RFC 7231 第 6.3.6 節：205 重設內容的規格，原始伺服器應該不會在回應酬載主體中傳送狀態碼 204 No Content 或 205 Reset Content。Content-Length、Content-Encoding 或 Transfer-Encoding 等回應標頭會指出回應酬載的大小、類型或格式。

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

	後端伺服器的狀態碼
後端伺服器的回應包含	204 沒有內容	205 重設內容
回應主體	錯誤	錯誤
Content-Length標題 (設為非零)	錯誤	錯誤
Content-Encoding (設為 Apigee Edge 中支援的編碼)	錯誤	沒有錯誤
Transfer-Encoding	錯誤	錯誤

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

原因	說明	適用的疑難排解指示
含有來自後端伺服器 204 回應的回應主體或標頭	後端伺服器會傳送 204 No Content 或 205 Reset Content 回應，其中包含回應主體和/或一或多個標頭 Content-Type、Content-Encoding 或 Transfer-Encoding。	Edge Public and Private Cloud 使用者

常見診斷步驟

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

原因：來自後端伺服器回應主體或標頭的 204 標頭

診斷

1. 使用 API 監控、追蹤工具或 NGINX 存取記錄檔，按照常見診斷步驟的說明，找出錯誤的「Fault Code」和「Fault Source」。
2. 如果「Fault Code」為 protocol.http.ResponseWithBody，且「Fault Source」的值為 target，則表示後端伺服器回應了 204 No Content 或 205 Reset Content 狀態碼，且回應內文和/或可能原因中提及的其中一個標頭。

3. 如要驗證後端伺服器是否確實傳送了回應酬載主體和/或「可能原因」一節所述的一或多個標頭，您可以執行下列步驟：

   1. 如果您是公用雲端使用者，而且能夠直接從任何系統向後端伺服器提出相同的 API 要求，

   2. 如果您是私人 Cloud 使用者，可以直接透過觀察到特定機構和環境的相關訊息處理者，向後端伺服器發出相同的 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 重設內容的規定。也就是說，後端伺服器「不得」在 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：

規格
RFC 7231 第 6.3.5 節：204 No Content
RFC 7231 第 6.3.6 節：205 重設內容

注意事項

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

如果仍需要 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