502 Bad Gateway - TooBigBody

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

Symptom

The client application gets an HTTP status code of 502 Bad Gateway with error code protocol.http.TooBigBody as a response for API calls.

Error message

Client application gets the following response code:

HTTP/1.1 502 Bad Gateway

In addition, you may observe the following error message:

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

Possible causes

This error occurs if the payload size sent by the target/backend server to Apigee Edge as part of HTTP response is greater than the allowed limit in Apigee Edge.

Here are the possible causes for the error:

Common diagnosis steps

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

Cause: Response Payload Size is greater than allowed limit

Diagnosis

1. Determine the Fault Code, Fault Source, and Response Payload Size for the error observed using API Monitoring, Trace tool, or NGINX access logs as explained in Common diagnosis steps with Scenario #1.
2. If the Fault Source has the value target, then this indicates that the response payload size sent by the target/backend server to Apigee is greater than the allowed limit in Apigee Edge.
3. Verify the Response Payload Size as determined from step 1.
   • If the payload size > 10 MB allowed limit, then that’s the cause for the error.
   • If the payload size ~ 10 MB allowed limit, then it’s possible that the response payload is passed in compressed format. Go to Cause: Response payload size exceeds allowed limit after decompression.
4. Validate that the response payload size is indeed > 10 MB allowed limit by checking the actual response using the following steps:
   1. If you don’t have access to the actual request made to the target/backend server, then go to Resolution.
   2. If you have access to the actual request made to the target/backend server, then perform the following steps:
      1. If you are a Public Cloud/Private Cloud user, make a request directly to the backend server from the backend server itself or any other machine from where you are allowed to make the request to the backend server.
      2. If you are a Private Cloud user, you can also make the request to the backend server from one of the Message Processors.
      3. Verify the size of the payload passed in the response by checking the Content-Length header.
      4. If you find that the size of the payload is more than the allowed limit in Apigee Edge, then that is the cause of the issue.

   Sample Response from the backend server:

   curl -v https://BACKENDSERVER-HOSTNAME/testfile
   

   * About to connect() to 10.14.0.10 port 9000 (#0)
   *   Trying 10.14.0.10...
   * Connected to 10.14.0.10 (10.148.0.10) port 9000 (#0)
   > GET /testfile HTTP/1.1
   > User-Agent: curl/7.29.0
   > Host: 10.14.0.10:9000
   > Accept: */*
   >
   < HTTP/1.1 200 OK
   < Accept-Ranges: bytes
   < Content-Length: 11534336
   < Content-Type: application/octet-stream
   < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
   < Date: Wed, 30 Jun 2021 09:22:41 GMT
   <
   ----snipped----
   <Response Body>

   In the above example, you can see that Content-Length: 11534336 (which is ~11 MB) which is the cause for this error as it exceeds the allowed limit in Apigee Edge.

Resolution

Refer to Resolution.

Cause: Response Payload Size exceeds allowed limit after decompression

If the response payload is sent in compressed format and the response header Content-Encoding is set to gzip, Apigee decompresses the response payload. During the decompression process, if Apigee finds the size of the payload to be greater than the allowed limit in Apigee Edge., then it stops further decompression and responds back immediately with 502 Bad Gateway and the error code protocol.http.TooBigBody.

Diagnosis

1. Determine the Fault Code, Fault Source and Response Payload size for the error observed using API Monitoring, Trace Tool or NGINX Access logs as explained in Common diagnosis steps with Scenario #2.
2. If the Fault Source has the value target, then this indicates that the response payload size sent by the target/backend application to Apigee is greater than the allowed limit in Apigee Edge.
3. Verify the Response Payload Size as determined from step 1.
   • If the payload size > 10 MB allowed limit, then that’s the cause for the error.
   • If the payload size ~ 10 MB allowed limit, then it’s possible that the response payload is passed in compressed format. In this case, check for the uncompressed size of the compressed response payload.
4. You can validate if the response from the target/backend was sent in compressed format and the uncompressed size was greater than the allowed limit using one of the following methods:

   Trace

   Using the Trace tool:

   1. If you have captured a trace for the failing request, refer to steps detailed in Trace and
      1. Determine the value of target.received.content.length
      2. Verify if the request from the client contained the Content-Encoding: gzip header
   2. If the value of target.received.content.length is around the 10 MB allowed limit, and the response header Content-Encoding: gzip, then that’s the cause for this error.

   Actual request

   Using actual request:

   1. If you don’t have access to the actual request made to the target/backend server, then go to Resolution.
   2. If you have access to the actual request made to the target/backend server, then perform the following steps:
      1. Verify the size of the payload passed in the response along with the Content-Encoding header sent in the response.
      2. If you find that the response header Content-Encoding is set to gzip and the uncompressed size of the payload is more than the allowed limit in Apigee Edge, then that’s the cause for this error.

         Sample response received from the backend server:

         curl -v https://BACKENDSERVER-HOSTNAME/testzippedfile.gz
         

         * About to connect() to 10.1.0.10 port 9000 (#0)
         *   Trying 10.1.0.10...
         * Connected to 10.1.0.10 (10.1.0.10) port 9000 (#0)
         > GET /testzippedfile.gz HTTP/1.1
         > User-Agent: curl/7.29.0
         > Host: 10.1.0.10:9000
         > Accept: */*
         >
         < HTTP/1.1 200 OK
         < Accept-Ranges: bytes
         < Content-Encoding: gzip
         < Content-Type: application/x-gzip
         < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
         < Testheader: test
         < Date: Wed, 07 Jul 2021 10:14:16 GMT
         < Transfer-Encoding: chunked
         <
         ----snipped----
         <Response Body>

         In the above case, the header Content-Encoding: gzip is sent and the size of the file testzippedfile.gz in the response is less than the limit, however the size of uncompressed file testzippedfile was ~15 MB.

   Message Processor logs

   Using Message Processor logs:

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

   2. Check the Message Processor logs

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

   3. Search to see if there are any 502 errors during a specific duration (if the problem happened in the past) or if there are any requests still failing with 502. You may use the following search strings:

      grep -ri "chunkCount"
      

      grep -ri "BadGateway: Body buffer overflow"
      

   4. You will find lines from system.log similar to as shown below (TotalRead and chunkCount may vary in your case):

      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.SERVICE -
      TrackingInputChannel.checkMessageBodyTooLarge() : Message is too large.
      TotalRead 10489856 chunkCount 2571
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.CLIENT -
      HTTPClient$Context.onInputException() :
      ClientInputChannel(ClientChannel[Connected:
      Remote:10.148.0.10:9000 Local:10.148.0.9:42240]@9155
      useCount=1 bytesRead=0 bytesWritten=182 age=23ms  lastIO=0ms
      isOpen=true).onExceptionRead exception: {}
      com.apigee.errors.http.server.BadGateway: Body buffer overflow
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR
      ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
      AbstractResponseListener.onError(HTTPResponse@77cbd7c4,
      Body buffer overflow)

   5. During the process of decompression, as soon as the Message Processor determines the total read bytes is > 10 MB, it stops and prints the following line:

      Message is too large. TotalRead 10489856 chunkCount 2571

      It implies that the Response Payload Size is more than 10 MB and Apigee throws the error when the size starts to exceed the limit 10 MB with fault code as protocol.http.TooBigBody

Resolution

Limits

Apigee expects the client application and backend server to not send payload sizes greater than the allowed limit as documented for Request/response size in Apigee Edge Limits.

1. If you are a Public Cloud user, then the maximum limit for request and response payload size is as documented for Request/response size in Apigee Edge Limits.
2. If you are a Private Cloud user, then you may have modified the default maximum limit for request and response payload size (even though it is not a recommended practice). You can determine the maximum request payload size limit by following instructions in How to check the current limit.

How to check the current limit?

This section explains how to verify that the property HTTPResponse.body.buffer.limit has been updated with a new value on the Message Processors.

1. On the Message Processor machine, search for the property HTTPResponse.body.buffer.limit in the /opt/apigee/edge-message- processor/conf directory and check to see what value has been set as shown below:

   grep -ri "HTTPResponse.body.buffer.limit" /opt/apigee/edge-message-processor/conf
   

2. The sample result from the above command is as follows:

   /opt/apigee/edge-message-processor/conf/http.properties:HTTPResponse.body.buffer.limit=10m

3. In the example output above, notice that the property HTTPResponse.body.buffer.limit has been set with the value 10m in http.properties.

   This indicates that the limit for the request payload size configured in Apigee for Private Cloud is 10 MB.

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 502 error
• Trace file for the API requests
• Complete output of the response from target/backend server along with the size of the payload

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

• Complete error message observed for the failing requests
• Organization name
• Environment name
• API Proxy bundle
• Trace file for the failing API requests
• Complete curl command used to reproduce the 502 error
• Complete output of the response from target/backend server along with the size of the payload

• 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