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 无内容 和 RFC 7231 第 6.3.6 节：205 重置内容，源服务器不应将任何其他内容 作为响应载荷正文的一部分发送，并返回状态代码 204 No Content 或 205 Reset Content。响应标头 （例如 Content-Length、Content-Encoding 或 Transfer-Encoding）表示响应载荷的大小、类型或格式。

因此，在以下情况下，Apigee Edge 会向客户端返回 502 Bad Gateway 状态代码，并返回错误代码 protocol.http.ResponseWithBody：

以下是造成此错误的可能原因：

常见诊断步骤

请使用以下工具/方法之一来诊断此错误：

原因：后端服务器返回的 204 响应包含响应正文或标头

诊断

1. 使用 API 监控、Trace 工具或 NGINX 访问日志确定观察到的错误的故障代码 和故障来源 ，如常见诊断步骤中所述。
2. 如果故障代码 为 protocol.http.ResponseWithBody，且 故障来源 的值为 target，则表示后端 服务器返回了 204 No Content 或 205 Reset Content 状态 代码，其中包含响应正文和/或“可能的原因”中提及的某个标头。

3. 如需验证后端服务器是否确实发送了响应载荷正文和/或一个 或多个“可能的原因”中提及的标头，您可以 执行以下步骤：

   1. 如果您是 Public Cloud 用户，并且可以直接从任何系统向 后端服务器发出相同的 API 请求。

   2. 如果您是 Private 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。

分辨率

确保后端服务器在向 Apigee Edge 发送 204 No Content 或 205 Reset Content 响应时，始终遵循规范 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：

需要注意的要点

建议的解决方案是修复后端服务器，使其发送 204 No Content 和 205 Reset Content 状态代码，而不包含响应正文和任何 标头（Content-Length、Content-Encoding 和 Transfer-Encoding），并遵循规范 RFC 7231 第 6.3.5 节：204 无内容 和 RFC 7231 第 6.3.6 节：205 重置内容。

如果您仍然需要 Apigee 支持团队的任何帮助，请前往 必须收集诊断信息。

必须收集的诊断信息

收集以下诊断信息，然后与 Apigee Edge 支持团队联系：

如果您是 Public Cloud 用户，请提供以下信息：

• 组织名称
• 环境名称
• API 代理名称
• 用于重现 502 错误的完整 curl 命令
• API 请求的跟踪文件

如果您是 Private Cloud 用户，请提供以下信息：

• 针对失败请求观察到的完整错误消息
• 环境名称
• API 代理软件包
• 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