502 Bad Gateway - TooBigBody

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

Síntoma

La aplicación cliente obtiene un código de estado HTTP 502 Bad Gateway con el código de error protocol.http.TooBigBody como respuesta a las llamadas a la API.

Mensaje de error

La aplicación cliente obtiene el siguiente código de respuesta: 

HTTP/1.1 502 Bad Gateway

Además, es posible que observes el siguiente mensaje de error: 

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

Causas posibles

Este error se produce si el tamaño de la carga útil que envía el servidor de destino o de backend a Apigee Edge como parte de la respuesta HTTP es mayor que el límite permitido en Apigee Edge.

Estas son las posibles causas del error:

Causa Descripción Instrucciones de solución de problemas aplicables para
El tamaño de la carga útil de la respuesta es mayor que el límite permitido El tamaño de la carga útil que envía el servidor de destino o de backend como parte de la respuesta HTTP a Apigee es mayor que el límite permitido en Apigee. Usuarios de la nube pública y privada de Edge
El tamaño de la carga útil de la respuesta supera el límite permitido después de la descompresión El tamaño de la carga útil que envía el servidor de destino o de backend en formato comprimido como parte de la respuesta HTTP a Apigee es mayor que el límite permitido cuando Apigee la descomprime. Usuarios de la nube pública y privada de Edge

Pasos comunes de diagnóstico

Usa una de las siguientes herramientas o técnicas para diagnosticar este error:

Supervisión de API

Para diagnosticar el error con API Monitoring, haz lo siguiente:

  1. Accede a la IU de Apigee Edge como usuario con un rol adecuado.

  2. Cambia a la organización en la que deseas investigar el problema.

  3. Navega a la página Analizar > Supervisión de API > Investigar.
  4. Selecciona el período específico en el que observaste los errores.
  5. Puedes seleccionar el filtro Proxy para reducir la cantidad de códigos de error.
  6. Representa gráficamente el código de falla en función del tiempo.

  7. Selecciona una celda que tenga el código de falla protocol.http.TooBigBody, como se muestra a continuación:

  8. Verás la información sobre el código de falla protocol.http.TooBigBody como se muestra a continuación:

  9. Haz clic en Ver registros y expande la fila de la solicitud con errores.

  10. En la ventana Logs, anota los siguientes detalles:
    • Código de estado: 502
    • Fuente del error: target
    • Código de falla: protocol.http.TooBigBody.
  11. Si la Fuente de error tiene el valor target y el Código de error tiene el valor protocol.http.TooBigBody, esto indica que la respuesta HTTP del servidor de destino o de backend tiene un tamaño de carga útil de respuesta mayor que el límite permitido en Apigee Edge.

Seguimiento

Para diagnosticar el error con la herramienta Trace, haz lo siguiente:

  1. Habilita la sesión de registro y realiza una de las siguientes acciones:
    • Espera a que se produzca el error 502 Bad Gateway.
    • Si puedes reproducir el problema, haz la llamada a la API y reproduce el error 502 Bad Gateway.
  2. Selecciona una de las solicitudes con errores y examina el registro.
  3. Navega por las diferentes fases del registro y ubica dónde se produjo la falla.

  4. Navega a la fase Error justo después de la fase Response received from target server, como se muestra a continuación:

    Observa los valores del error del registro:

    • error: Body buffer overflow
    • error.class: com.apigee.errors.http.server.BadGateway

    Esto indica que Apigee Edge (componente Message Processor) arroja el error en cuanto recibe la respuesta del servidor de backend debido a que el tamaño de la carga útil supera el límite permitido.

  5. Verás el error en la fase Response Sent to Client, como se muestra a continuación:

  6. Observa los valores del error del registro. El registro de seguimiento de ejemplo anterior muestra lo siguiente:
    • error: 502 Bad Gateway
    • Contenido del error: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}

  7. Navega a la fase Response Received from target server, como se muestra a continuación para diferentes situaciones:

    Sin comprimir

    Situación 1: Carga útil de la respuesta enviada sin comprimir

    Observa los valores del error del registro:

    • Respuesta recibida del servidor de destino: 200 OK
    • Content-Length (de la sección Encabezados de respuesta): ~11 MB

    Comprimido

    Situación 2: Carga útil de la solicitud enviada en formato comprimido

    Observa los valores del error del registro:

    • Respuesta recibida del servidor de destino: 200 OK
    • Content-Encoding: Si ves este encabezado en la sección Encabezados de respuesta, anota el valor. Por ejemplo, en este caso, el valor es gzip.

  8. Observa el Cuerpo en la sección Contenido de la respuesta:

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

  9. Navega a la fase AX (datos de Analytics registrados) en el registro y haz clic en ella para ver los detalles relacionados.

  10. Desplázate hacia abajo en Detalles de la fase hasta la sección Variables Read y determina los valores de target.received.content.length, que indican lo siguiente:
    • El tamaño real de la carga útil de la respuesta cuando se envía en formato sin comprimir
    • Es el tamaño de la carga útil de la respuesta después de la descompresión por parte de Apigee, cuando la carga útil se envía en formato comprimido. Siempre será el mismo que el valor del límite permitido (10 MB) en este caso.

    Sin comprimir

    Situación 1: Carga útil de la respuesta enviada sin comprimir

    Ten en cuenta el valor de target.received.content.length:

    Encabezados de la solicitud Valor
    target.received.content.length ~11 MB

    Comprimido

    Situación 2: Carga útil de la solicitud enviada en formato comprimido

    Ten en cuenta el valor de target.received.content.length:

    Encabezados de la solicitud Valor
    target.received.content.length ~10 MB

  11. En la siguiente tabla, se explica por qué Apigee devuelve el error 502 en los dos casos según el valor de target.received.content.length:

    Situación Valor de target.received.content.length Motivo del error
    Carga útil de la respuesta en formato sin comprimir ~11 MB El tamaño supera el límite permitido de 10 MB
    Carga útil de la respuesta en formato comprimido ~10 MB

    Se superó el límite de tamaño tras la descompresión

NGINX

Para diagnosticar el error con los registros de acceso de NGINX, haz lo siguiente:

  1. Si eres usuario de Private Cloud, puedes usar los registros de acceso de NGINX para determinar la información clave sobre los errores de HTTP 502.

  2. Verifica los registros de acceso de NGINX:

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

    Dónde: ORG, ENV y PORT# se reemplazan por valores reales.

  3. Busca si hay errores de 502 durante un período específico (si el problema ocurrió en el pasado) o si aún hay solicitudes que fallan con 502.
  4. Si encuentras errores de 502 con el X-Apigee-fault-code que coincida con el valor de protocol.http.TooBigBody, determina el valor de X-Apigee-fault-source.

    Ejemplo de error 502 del registro de acceso de NGINX:

    La entrada de ejemplo anterior del registro de acceso de NGINX tiene los siguientes valores para X-Apigee-fault-code y X-Apigee-fault-source:

    Encabezados de respuesta Valor
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source target

Causa: El tamaño de la carga útil de la respuesta es mayor que el límite permitido

Diagnóstico

  1. Determina el código de error, la fuente del error y el tamaño de la carga útil de la respuesta para el error observado con API Monitoring, la herramienta Trace o los registros de acceso de NGINX, como se explica en los pasos de diagnóstico comunes del caso 1.
  2. Si la fuente de la falla tiene el valor target, esto indica que el tamaño de la carga útil de la respuesta que envía el servidor de destino o de backend a Apigee es mayor que el límite permitido en Apigee Edge.
  3. Verifica el tamaño de la carga útil de la respuesta según lo determinado en el paso 1.
  4. Valida que el tamaño de la carga útil de la respuesta sea superior al límite permitido de 10 MB. Para ello, verifica la respuesta real con los siguientes pasos:
    1. Si no tienes acceso a la solicitud real que se realizó al servidor de destino o de backend, ve a Resolución.
    2. Si tienes acceso a la solicitud real que se envió al servidor de destino o backend, sigue estos pasos:
      1. Si eres usuario de nube pública o privada, realiza una solicitud directamente al servidor de backend desde el mismo servidor o cualquier otra máquina desde la que se te permita realizar la solicitud al servidor de backend.
      2. Si eres usuario de la nube privada, también puedes realizar la solicitud al servidor de backend desde uno de los procesadores de mensajes.
      3. Verifica el tamaño de la carga útil que se pasó en la respuesta. Para ello, revisa el encabezado Content-Length.
      4. Si detectas que el tamaño de la carga útil supera el límite permitido en Apigee Edge, esa es la causa del problema.

    Ejemplo de respuesta del servidor de backend:

    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>

    En el ejemplo anterior, puedes ver que Content-Length: 11534336 (which is ~11 MB) es la causa de este error, ya que supera el límite permitido en Apigee Edge.

Solución

Consulta Resolución.

Causa: El tamaño de la carga útil de la respuesta supera el límite permitido después de la descompresión

Si la carga útil de la respuesta se envía en formato comprimido y el encabezado de respuesta Content-Encoding se establece en gzip, , Apigee descomprime la carga útil de la respuesta. Durante el proceso de descompresión, si Apigee detecta que el tamaño de la carga útil es mayor que el límite permitido en Apigee Edge, detiene la descompresión y responde de inmediato con 502 Bad Gateway y el código de error protocol.http.TooBigBody.

Diagnóstico

  1. Determina el código de error, la fuente del error y el tamaño de la carga útil de la respuesta para el error observado con la Supervisión de API, la herramienta Trace o los registros de acceso de NGINX, como se explica en los pasos de diagnóstico comunes del caso práctico 2.
  2. Si la Fuente de la falla tiene el valor target, esto indica que el tamaño de la carga útil de la respuesta que envía la aplicación de destino o de backend a Apigee es mayor que el límite permitido en Apigee Edge.
  3. Verifica el tamaño de la carga útil de la respuesta según lo determinado en el paso 1.
    • Si el tamaño de la carga útil es superior al límite permitido de 10 MB, esa es la causa del error.
    • Si el tamaño de la carga útil es de aproximadamente 10 MB, el límite permitido, es posible que la carga útil de la respuesta se pase en formato comprimido. En este caso, verifica el tamaño sin comprimir de la carga útil de la respuesta comprimida.
  4. Puedes validar si la respuesta del backend o destino se envió en formato comprimido y si el tamaño sin comprimir fue mayor que el límite permitido con uno de los siguientes métodos:

    Seguimiento

    Cómo usar la herramienta de Trace:

    1. Si capturaste un registro de seguimiento de la solicitud que falló, consulta los pasos detallados en Registro de seguimiento y
      1. Determina el valor de target.received.content.length
      2. Verifica si la solicitud del cliente contenía el encabezado Content-Encoding: gzip .
    2. Si el valor de target.received.content.length se acerca al límite permitido de 10 MB y el encabezado de respuesta Content-Encoding: gzip, entonces esa es la causa de este error.

    Solicitud real

    Uso de la solicitud real:

    1. Si no tienes acceso a la solicitud real que se realizó al servidor de destino o backend, ve a Resolución.
    2. Si tienes acceso a la solicitud real que se envió al servidor de destino o backend, sigue estos pasos:
      1. Verifica el tamaño de la carga útil que se pasó en la respuesta junto con el encabezado Content-Encoding que se envió en la respuesta.
      2. Si ves que el encabezado de respuesta Content-Encoding está establecido en gzip y el tamaño sin comprimir de la carga útil es mayor que el límite permitido en Apigee Edge, esa es la causa de este error.

        Ejemplo de respuesta recibida del servidor de backend:

        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>

        En el caso anterior, se envía el encabezado Content-Encoding: gzip y el tamaño del archivo testzippedfile.gz en la respuesta es inferior al límite. Sin embargo, el tamaño del archivo sin comprimir testzippedfile era de aproximadamente 15 MB.

    Registros de Message Processor

    Cómo usar los registros del Message Processor:

    1. Si eres usuario de Private Cloud, puedes usar los registros de Message Processor para determinar la información clave sobre los errores de HTTP 502.

    2. Verifica los registros del Message Processor

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

    3. Busca si hay errores de 502 durante un período específico (si el problema ocurrió en el pasado) o si hay solicitudes que siguen fallando con 502. Puedes usar las siguientes cadenas de búsqueda:

      grep -ri "chunkCount"

      grep -ri "BadGateway: Body buffer overflow"
    4. Encontrarás líneas de system.log similares a las que se muestran a continuación (TotalRead y chunkCount pueden variar en tu caso): 
      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. Durante el proceso de descompresión, en cuanto el Message Processor determina que los bytes totales leídos son superiores a 10 MB, se detiene y muestra la siguiente línea:

      Message is too large. TotalRead 10489856 chunkCount 2571

      Esto implica que el tamaño de la carga útil de la respuesta es superior a 10 MB y Apigee muestra el error cuando el tamaño comienza a superar el límite de 10 MB con el código de error protocol.http.TooBigBody.

Solución

Tamaño fijo

Opción 1 [recomendada]: Corrige la aplicación del servidor de destino para que no envíe cargas útiles con un tamaño que supere el límite de Apigee

  1. Analiza el motivo por el que el servidor de destino específico envía un tamaño de respuesta o carga útil superior al límite permitido, según se define en Límites.
  2. Si no es deseable, modifica la aplicación del servidor de destino para que envíe un tamaño de respuesta o carga útil inferior al límite permitido.
  3. Si es deseable y quieres enviar una respuesta o una carga útil que supere el límite permitido, consulta las siguientes opciones.

Patrón de URL firmada

Opción 2 [recomendada]: Usa el patrón de URLs firmadas dentro de una política JavaCallout de Apigee

Para las cargas útiles de más de 10 MB, Apigee recomienda usar un patrón de URLs firmadas dentro de un JavaCallout de Apigee, que se ilustra con el ejemplo de Edge Callout: Signed URL Generator en GitHub.

Transmisión

Opción 3: Usa la transmisión

Si tu proxy de API necesita controlar solicitudes o respuestas muy grandes, puedes habilitar la transmisión en Apigee.

CwC

Opción 4: Usa la propiedad CwC para aumentar el límite del búfer

Esta opción solo se debe usar cuando no se puede usar ninguna de las opciones recomendadas, ya que puede haber problemas de rendimiento si se aumenta el tamaño predeterminado.

Apigee proporciona una propiedad CwC que le permite aumentar el límite de tamaño de la carga útil de la solicitud y la respuesta. Para obtener más detalles, consulta Cómo establecer el límite de tamaño del mensaje en el router o el Message Processor.

Límites

Apigee espera que la aplicación cliente y el servidor de backend no envíen tamaños de carga útil mayores que el límite permitido, como se documenta para Request/response size en Límites de Apigee Edge.

  1. Si eres usuario de la nube pública, el límite máximo para el tamaño de la carga útil de solicitud y respuesta es el que se documenta para Request/response size en Límites de Apigee Edge.
  2. Si eres usuario de Private Cloud, es posible que hayas modificado el límite máximo predeterminado para el tamaño de la carga útil de la solicitud y la respuesta (aunque no es una práctica recomendada). Para determinar el límite máximo de tamaño de la carga útil de la solicitud, sigue las instrucciones que se indican en Cómo verificar el límite actual.

¿Cómo puedo verificar el límite actual?

En esta sección, se explica cómo verificar que la propiedad HTTPResponse.body.buffer.limit se haya actualizado con un valor nuevo en los procesadores de mensajes.

  1. En la máquina del Message Processor, busca la propiedad HTTPResponse.body.buffer.limit en el directorio /opt/apigee/edge-message- processor/conf y verifica qué valor se estableció, como se muestra a continuación:

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

  2. El resultado de muestra del comando anterior es el siguiente:

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

  3. En el resultado de ejemplo anterior, observa que la propiedad HTTPResponse.body.buffer.limit se estableció con el valor 10m en http.properties.

    Esto indica que el límite para el tamaño de la carga útil de la solicitud configurado en Apigee para Private Cloud es de 10 MB.

Si aún necesitas ayuda del equipo de asistencia de Apigee, consulta Recopila información de diagnóstico.

Se debe recopilar información de diagnóstico

Recopila la siguiente información de diagnóstico y, luego, comunícate con el equipo de asistencia de Apigee Edge:

Si eres usuario de la nube pública, proporciona la siguiente información:

  • Nombre de la organización
  • Nombre del entorno
  • Nombre del proxy de API
  • Comando curl completo que se usa para reproducir el error 502
  • Archivo de registro de las solicitudes a la API
  • Salida completa de la respuesta del servidor de destino o backend, junto con el tamaño de la carga útil

Si eres usuario de la nube privada, proporciona la siguiente información:

  • Mensaje de error completo observado para las solicitudes con errores
  • Nombre de la organización
  • Nombre del entorno
  • Paquete de proxy de API
  • Archivo de registro de las solicitudes a la API con errores
  • Comando curl completo que se usa para reproducir el error 502
  • Salida completa de la respuesta del servidor de destino o backend, junto con el tamaño de la carga útil

  • Registros de acceso de NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    Dónde: ORG, ENV y PORT# se reemplazan por valores reales.

  • Registros del sistema de Message Processor /opt/apigee/var/log/edge-message-processor/logs/system.log