400 Bad Request - 解压缩失败的 Request

<ph type="x-smartling-placeholder"></ph> 您正在查看 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 标头。

<ph type="x-smartling-placeholder">

下面列举了一些受支持的 Content-Encoding值示例，以及 Apigee Edge 如何 在以下情况下，载荷格式应为：

场景	Content-Encoding	预期的载荷格式
单一编码	gzip	Unix gzip 格式。 请参阅 <ph type="x-smartling-placeholder"></ph> RFC1952 GZIP 格式。
单一编码	缩小	此格式使用 zlib 结构和 deflate 压缩算法。 请参阅 RFC1950 和 <ph type="x-smartling-placeholder"></ph> RFC1951.
多重编码	多重编码 例如，如果编码进行了两次，则可能是： gzip、deflate gzip、gzip deflate、gzip deflate、deflate	按标头中显示的指定顺序对载荷应用多种编码。

导致此错误的可能原因如下：

原因	说明	适用的问题排查说明
<ph type="x-smartling-placeholder"></ph> 请求载荷格式与 Content-Encoding 标头中指定的编码不匹配	客户端发送的请求载荷的格式未编码或未编码 与 Content-Encoding 标头中指定的编码匹配。	Edge 公有云和私有云用户

常见诊断步骤

使用以下工具/技术之一来诊断此错误：

原因：请求负载的格式与指定的编码不匹配 在 Content-Encoding 标头中

默认情况下，如果有请求标头，Apigee Edge 始终会对载荷进行解压缩 Content-Encoding 包含有效的和 <ph type="x-smartling-placeholder"></ph> 支持的编码。因此，请求载荷的格式应该 应匹配在请求标头 Content-Encoding 中指定的编码。 如果存在不匹配，就会收到此错误。

诊断

1. 确定使用 API 观察到的错误的错误代码和错误来源 监控、跟踪工具或 NGINX 访问日志，如 常见的诊断步骤。
2. 如果错误代码是 messaging.adaptors.http.flow.DecompressionFailureAtRequest 和 故障来源的值为 policy 或 proxy，则此 表示客户端应用发送的请求包含的负载 请求标头 Content-Encoding 中指定的受支持编码。

3. 您可以使用以下任一方法在 HTTP 请求中确定不匹配问题 方法：

   错误消息

   如需使用错误消息进行验证，请执行以下操作：

   1. 如果您有权查看从 Apigee Edge 收到的完整错误消息，则： 请参阅 faultstring。

      示例错误消息：

      "faultstring":"Decompression failure at request"
      

   2. 在上述错误消息中， "Decompression failure at request"，这意味着请求 使用 Content-Encoding 标头。

   Trace

   如需使用 Trace 进行验证，请执行以下操作：

   1. 确定请求标头 Content-Encoding 的值 属性 error.cause（使用 Trace） 如常见诊断步骤中所述。

   2. 示例跟踪记录中的值如下所示：

      • Content-Encoding：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 标头的值在 <ph type="x-smartling-placeholder"></ph> 支持的编码，但请求负载的格式 与 Content-Encoding 标头中指定的编码匹配， 那么这就是出现问题的原因

      示例请求：

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

      上面的示例请求会将值 gzip 发送到 Content-Encoding 标头， <ph type="x-smartling-placeholder"></ph> 支持的编码。但是，请求载荷 request_payload.zip 采用 ZIP 格式。因此，该要求 失败，并显示 400 Bad Request 状态代码和错误代码： messaging.adaptors.http.flow.DecompressionFailureAtRequest。

   消息处理器日志

   <ph type="x-smartling-placeholder">

   如需使用消息处理器日志进行验证，请执行以下操作：

   如果您是 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 表示请求有效负载不是在 deflate 格式，并且它与 deflate 的 Content-Encoding 标头。因此，Apigee Edge 会抛出异常并返回 400 状态代码， 错误代码 messaging.adaptors.http.flow.DecompressionFailureAtRequest 。

分辨率

1. 如果不需要在 Apigee Edge 的 API 代理流程中使用压缩的请求载荷 在后端服务器中，则不要传递标头 Content-Encoding。 如果需要压缩请求载荷，请转到第 2 步。
2. 确保客户端应用始终发送以下内容： <ph type="x-smartling-placeholder">
   </ph>
   • 以下任何一项： <ph type="x-smartling-placeholder"></ph> 支持的编码作为 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
   

规范

Apigee Edge 返回状态代码 400 Bad Request 以及错误代码 messaging.adaptors.http.flow.DecompressionFailureAtRequest（根据以下 RFC） 规范：

规范
<ph type="x-smartling-placeholder"></ph> RFC 7231，第 6.5.1 节
<ph type="x-smartling-placeholder"></ph> RFC 7231，第 3.1.2.2 节

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

必须收集的诊断信息

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

如果您是公有云用户，请提供以下信息：

• 组织名称
• 环境名称
• API 代理名称
• 完成用于重现 400 错误的 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