400 Bad Request - DecompressionFailureAtRequest

You're viewing Apigee Edge documentation.
Go to the Apigee X documentation. info

Symptom

The client application gets an HTTP status code of 400 Bad Request with error code messaging.adaptors.http.flow.DecompressionFailureAtRequest as a response to API calls.

Error message

Client application gets the following response code:

HTTP/1.1 400 Bad Request

In addition, you may observe an error message similar to the one shown below:

{
   "fault":{
      "faultstring":"Decompression failure at request",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"
      }
   }
}

Possible causes

This error occurs only if:

• The encoding specified in the HTTP request header Content-Encoding is valid and supported by Apigee Edge,

BUT

• The payload format sent by the client as part of the HTTP request does not match the encoding format specified in the Content-Encoding header

This is because Apigee Edge fails to decode the payload using the specified encoding since the format of the payload is not in the same format as the encoding specified in the Content-Encoding header.

Here are few examples of supported Content-Encoding values and how Apigee Edge expects the payload format to be in those cases:

The possible causes for this error are as follows:

Common diagnosis steps

Use one of the following tools/techniques to diagnose this error:

Cause: Request payload format does not match the encoding specified in Content-Encoding header

By default, Apigee Edge always decompresses the payload if the request header Content-Encoding contains a valid and a supported encoding. Therefore, it is expected that the format of the request payload should match the encoding specified in the request header Content-Encoding. If there is a mismatch, then you get this error.

Diagnosis

1. Determine the Fault Code and Fault Source for the error observed using API Monitoring, Trace tool or NGINX access logs as explained in Common diagnosis steps.
2. If the Fault Code is messaging.adaptors.http.flow.DecompressionFailureAtRequest and the Fault Source has the value policy or proxy, then this indicates that the request sent by the client application has payload which does not match the supported encoding specified in the request header Content-Encoding.

3. You can determine the mismatch as part of the HTTP request using one of the following methods:

   Error message

   To validate using the error message:

   1. If you have access to the complete error message received from Apigee Edge, then refer to the faultstring.

      Sample error message:

      "faultstring":"Decompression failure at request"

   2. In the above error message, it displays "Decompression failure at request" which implies that the request could not be decompressed using the encoding specified in the Content-Encoding header.

   Trace

   To validate using the Trace:

   1. Determine the value of the request header Content-Encoding and the property error.cause using Trace as explained in Common diagnosis steps.

   2. The values from the sample trace are as follows:

      • Content-Encoding: gzip
      • error.cause: Not in GZIP format

      The value in the request header Content-Encoding is gzip; however, the request payload is not in GZIP format (as indicated by error.cause). Therefore, Apigee Edge responds with 400 Bad Request and error code messaging.adaptors.http.flow.DecompressionFailureAtRequest.

   Actual request

   To validate using the actual request:

   If you have access to the actual request made by the client application, then perform the following steps:

   1. Determine the value passed to the request header Content-Encoding.
   2. Determine the format of the payload sent as part of the request.

   3. If the value of Content-Encoding header is in the list of supported encoding but the format of the request payload does not match with the encoding specified in Content-Encoding header, then that is the cause of the issue.

      Sample request:

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

      The above sample request sends the value gzip to the Content-Encoding header which is a supported encoding in Apigee Edge. However, the request payload request_payload.zip is in ZIP format. Therefore, this request fails with a 400 Bad Request status code and the error code: messaging.adaptors.http.flow.DecompressionFailureAtRequest.

   Message Processor logs

   To validate using Message Processor logs:

   If you are a Private Cloud user, then you can use Message Processor logs to determine the key information about HTTP 400 errors.

   1. Determine the message ID of the failing request using API Monitoring, Trace tool, or NGINX access logs as explained in Common diagnosis steps.

   2. Search for the message ID in the Message Processor log:

      /opt/apigee/var/log/edge-message-processor/logs/system.log

   3. You will see one of the following exceptions:

      Scenario #1

      Scenario #1: When API request has the header 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
      

      The line java.util.zip.ZipException: Not in GZIP format in the above error message indicates that the request payload is not sent in GZIP format although the Content-Encoding is specified as gzip. Therefore, Apigee Edge throws the exception and returns a 400 status code with fault code messaging.adaptors.http.flow.DecompressionFailureAtRequest to client applications.

      Scenario #2

      Scenario #2: When API request has the header 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)
      

      The lines java.util.zip.ZipException: incorrect header check and Caused by: java.util.zip.DataFormatException: incorrect header check in the above error message indicate that the request payload is not sent in deflate format and does not match the encoding specified in the Content-Encoding header of deflate. Therefore, Apigee Edge throws the exception and returns a 400 status code with fault code messaging.adaptors.http.flow.DecompressionFailureAtRequest to client applications.

Resolution

1. If there's no need for the compressed request payload in the API proxy flow in Apigee Edge and in the backend server, then do not pass the header Content-Encoding. If there is a need to compress the request payload, go to step 2.
2. Ensure that the client application always sends the following:
   • Any of the supported encoding as the value for the Content-Encoding header in the request
   • The request payload in the supported format to Apigee Edge matches the encoding format specified in Content-Encoding header
3. In the example discussed above, the request payload is in ZIP format but the request header specifies Content-Encoding: gzip. You can fix the issue by sending the request header as Content-Encoding: gzip and the request payload also in gzip format:

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

Specification

Apigee Edge responds with the status code 400 Bad Request with error code messaging.adaptors.http.flow.DecompressionFailureAtRequest as per the following RFC specifications:

If you still need any assistance from Apigee Support, go to Must gather diagnostic information.

Must gather diagnostic information

Gather the following diagnostic information, and then contact Apigee Edge Support:

If you are a Public Cloud user, provide the following information:

• Organization name
• Environment name
• API Proxy name
• Complete curl command used to reproduce the 400 error
• Trace file for the API requests

If you are a Private Cloud user, provide the following information:

• Complete error message observed for the failing requests
• Environment name
• API Proxy bundle
• Trace file for the API requests

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

  Where: ORG, ENV and PORT# are replaced with actual values.

• Message Processor system logs /opt/apigee/var/log/edge-message-processor/logs/system.log