Entidad de solicitud demasiado grande 413 - 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 de 413 Request Entity Too Large 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 413 Request Entity Too Large

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 la aplicación cliente a Apigee Edge como parte de la solicitud HTTP es mayor que el límite permitido en Apigee Edge .

Estas son las posibles causas de este error :

Causa Descripción Instrucciones de solución de problemas aplicables para
El tamaño de la carga útil de la solicitud es mayor que el límite permitido El tamaño de la carga útil que envía la aplicación cliente como parte de la solicitud HTTP a Apigee Edge es mayor que el límite permitido en Apigee Edge. Usuarios de la nube pública y privada de Edge
El tamaño de la carga útil de la solicitud supera el límite permitido después de la descompresión El tamaño de la carga útil que envía la aplicación cliente en formato comprimido como parte de la solicitud HTTP a Apigee Edge es mayor que el límite permitido cuando Apigee Edge 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 y el código de estado 413, como se muestra a continuación:

  8. La información sobre el código de falla protocol.http.TooBigBody se muestra como se indica a continuación:

  9. Haz clic en Ver registros y expande la fila de la solicitud con errores. Luego, en la ventana Registros, observa los detalles como se muestran a continuación :

    Sin comprimir

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

    En la ventana Logs, ten en cuenta los siguientes detalles:

    • Código de estado: 413
    • Fuente del error: proxy
    • Código de falla: protocol.http.TooBigBody.
    • Longitud de la solicitud(bytes): 15360440 (aproximadamente 15 MB)

    Si la Fuente de error tiene el valor proxy, el Código de error tiene el valor protocol.http.TooBigBody y la Longitud de la solicitud es superior a 10 MB, esto indica que la solicitud HTTP del cliente tiene un tamaño de carga útil de solicitud mayor que el límite permitido en Apigee.

    Comprimido

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

    En la ventana Registros, ten en cuenta los siguientes detalles:

    • Código de estado: 413
    • Fuente del error: proxy
    • Código de falla: protocol.http.TooBigBody.
    • Longitud de la solicitud(bytes): 15264 (aproximadamente 15 KB)

    Si la Fuente de error tiene el valor proxy, el Código de error tiene el valor protocol.http.TooBigBody y la Longitud de la solicitud es inferior a 10 MB, esto indica que la solicitud HTTP del cliente tiene un tamaño de carga útil de solicitud inferior al límite permitido en su formato comprimido, pero el tamaño de la carga útil es superior al límite permitido cuando Apigee la descomprime.

Seguimiento

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

  1. Habilita la sesión de registro y una de las siguientes opciones:
    • Espera a que se produzca el error 413 Request Entity Too Large.
    • Si puedes reproducir el problema, realiza la llamada a la API y reproduce el error 413 Request Entity Too Large.

  2. Asegúrate de que la opción Show all Flow Infos esté habilitada.

  3. Selecciona una de las solicitudes con errores y examina el registro.
  4. Navega a la fase Solicitud recibida del cliente.

    Sin comprimir

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

    Toma nota de la siguiente información:

    • Content-Encoding: No está presente
    • Content-Length: 15360204

    Comprimido

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

    Toma nota de la siguiente información:

    • Content-Encoding: gzip
    • Content-Length: 14969
    • Content-Type: application/x-gzip
  5. Navega por las diferentes fases del registro y ubica dónde se produjo la falla.

  6. Por lo general, encontrarás el error en un flujo después de la fase Solicitud recibida del cliente, como se muestra a continuación:

  7. Observa el valor del error del registro. El registro de seguimiento de ejemplo anterior muestra lo siguiente:
    • error: Body buffer overflow
    • error.class: com.apigee.errors.http.user.RequestTooLarge

  8. Navega a Response Sent to Client y anota los valores del error del registro. El siguiente registro de muestra muestra lo siguiente:

    • error: 413 Request Entity Too Large
    • Contenido del error: {"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.

  10. En la sección Detalles de la fase, desplázate hacia abajo hasta Variables Read.

  11. Determina el valor de la variable client.received.content.length, que indica lo siguiente:
    • El tamaño real de la carga útil de la solicitud cuando se envía en formato sin comprimir
    • Tamaño de la carga útil de la solicitud 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 solicitud sin comprimir

    Variable client.received.content.length: 15360204

    Comprimido

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

    Variable client.received.content.length: 10489856

  12. En la siguiente tabla, se explica por qué Apigee devuelve el error 413 en los dos casos según el valor de la variable client.received.content.length:
    Situación Valor de client.received.content.length Motivo del error
    Carga útil de la solicitud en formato sin comprimir ~15 MB El tamaño supera el límite permitido de 10 MB.
    Carga útil de la solicitud 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 413.

  2. Verifica los registros de acceso de NGINX:

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

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

    Sin comprimir

    Situación 1 : Tamaño de la carga útil de la solicitud en formato sin comprimir

    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-sourc policy

    Observa la Longitud de la solicitud: 15360440 (14.6 MB > límite permitido)

    Comprimido

    Situación 2 : Tamaño de la carga útil de la solicitud en formato comprimido

    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 policy

    Ten en cuenta la longitud de la solicitud: 15264 (14.9 K < límite permitido)

    En esta situación, Apigee Edge devuelve 413, aunque la longitud de la solicitud sea inferior al límite permitido, ya que es posible que la solicitud se haya enviado en formato comprimido y el tamaño de la carga útil supere el límite tras la descompresión por parte de Apigee Edge.

Causa: El tamaño de la carga útil de la solicitud 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 solicitud 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 con el escenario 1 (sin comprimir).
  2. Si la Fuente de error tiene el valor policy o proxy, esto indica que el tamaño de la carga útil de la solicitud que envía la aplicación cliente a Apigee es mayor que el límite permitido en Apigee Edge.
  3. Verifica el tamaño de la carga útil de la solicitud según lo determinado en el paso 1.
  4. También puedes validar si el tamaño de la carga útil de la solicitud es realmente superior al límite permitido de 10 MB. Para ello, sigue estos pasos para verificar la solicitud real:
    1. Si no tienes acceso a la solicitud real que realizó la aplicación cliente, ve a Resolución.
    2. Si tienes acceso a la solicitud real que realizó la aplicación cliente, sigue estos pasos:
      1. Verifica el tamaño de la carga útil que se pasó en la solicitud.
      2. Si detectas que el tamaño de la carga útil supera el límite permitido en Apigee Edge, esa es la causa del problema.

        3. Solicitud de ejemplo:

        curl http://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile -v

        En el caso anterior, el archivo test15mbfile tiene un tamaño de aproximadamente 15 MB. Si usas otro cliente, obtén los registros del cliente para conocer el tamaño de la carga útil que se envía.

Solución

Ve a Resolución.

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

Si la carga útil de la solicitud se envía en formato comprimido y el encabezado de la solicitud Content-Encoding se establece en gzip, , Apigee descomprime la carga útil de la solicitud. Durante el proceso de descompresión, si Apigee detecta que el tamaño de la carga útil es superior a 10 MB, el límite permitido, detiene la descompresión y responde de inmediato con 413 Request Entity Too Large 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 solicitud para el error observado con la supervisión de API, la herramienta de Trace o los registros de acceso de NGINX, como se explica en los pasos de diagnóstico comunes con el caso 2 (comprimido).
  2. Si la Fuente de error tiene el valor policy o proxy, esto indica que el tamaño de la carga útil de la solicitud que envía la aplicación cliente a Apigee es mayor que el límite permitido en Apigee Edge.
  3. Verifica el tamaño de la carga útil de la solicitud 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 inferior al límite permitido de 10 MB, es posible que la carga útil de la solicitud se pase en formato comprimido. En este caso, verifica el tamaño sin comprimir de la carga útil de la solicitud comprimida.
  4. Puedes validar si la solicitud del cliente 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

    Para realizar la validación con la herramienta de seguimiento, sigue estos pasos:

    1. Si capturaste un registro de seguimiento para la solicitud con errores, consulta los pasos detallados en Registro de seguimiento y
      1. Determina el valor de la variable client.received.content.length
      2. Verifica si la solicitud del cliente contenía el encabezado Content-Encoding: gzip .
    2. Si el valor de la variable client.received.content.length es mayor que 10 MB, el límite permitido, y el encabezado de la solicitud Content-Encoding: gzip, esa es la causa de este error.

    Solicitud real

    Para validar con la solicitud real, haz lo siguiente:

    1. Si no tienes acceso a la solicitud real que realizó la aplicación cliente, ve a Resolución.
    2. Si tienes acceso a la solicitud real que realizó la aplicación cliente, sigue estos pasos:
      1. Verifica el tamaño de la carga útil que se pasó en la solicitud junto con el encabezado Content-Encoding que se envió en la solicitud.

      2. Verifica si el tamaño sin comprimir de la carga útil es mayor que el límite permitido en Apigee Edge.

        Solicitud de muestra:

        curl https://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile.gz -H "Content-Encoding: gzip" -v

        En el caso anterior, el archivo test15mbfile.gz es inferior al límite de tamaño; sin embargo, el tamaño del archivo sin comprimir test15mbfile es de aproximadamente 15 MB y el encabezado Content-Encoding es gzip.

        Si usas otro cliente, obtén los registros del cliente para averiguar el tamaño de la carga útil que se envía y si el encabezado Content-Encoding está configurado como gzip.

    Registros de Message Processor

    Para realizar la validación con los registros de Message Processor, haz lo siguiente:

    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 413.

    2. Verifica los registros del Message Processor:

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

    3. Busca si hay errores de 413 durante un período específico (si el problema ocurrió en el pasado) o si aún hay solicitudes que fallan con 413.

      Puedes usar las siguientes cadenas de búsqueda:

      grep -ri "chunkCount"

      grep -ri "RequestTooLarge"
    4. Encontrarás líneas de system.log similares a las siguientes (TotalRead y chunkCount pueden variar en tu caso): 
      2021-07-06 13:29:57,544  NIOThread@1 ERROR HTTP.SERVICE -
  TrackingInputChannel.checkMessageBodyTooLarge()
  : Message is too large.  TotalRead 10489856 chunkCount 2570

2021-07-06 13:29:57,545  NIOThread@1 INFO  HTTP.SERVICE -
  ExceptionHandler.handleException()
  : Exception trace: com.apigee.errors.http.user.RequestTooLarge
  : Body buffer overflow
    5. Durante el proceso de descompresión, en cuanto el Message Processor determina que los bytes leídos totales son superiores a 10 MB, se detiene y muestra la siguiente línea: 
      Message is too large.  TotalRead 10489856 chunkCount 2570

      Esto implica que el tamaño de la carga útil de la solicitud es superior a 10 MB y Apigee arroja el error RequestTooLarge 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 cliente para que no envíe un tamaño de carga útil mayor que el límite permitido

  1. Analiza el motivo por el que el cliente específico envía un tamaño de solicitud o carga útil mayor que el límite permitido, según se define en Límites.

  2. Si no es deseable, modifica tu aplicación cliente para que envíe un tamaño de solicitud o carga útil inferior al límite permitido.

    En el ejemplo anterior, puedes solucionar el problema pasando un archivo de menor tamaño, por ejemplo, una carga útil de test5mbfile (con un tamaño de 5 MB), como se muestra a continuación: 

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
  3. Si es conveniente y quieres enviar una solicitud o una carga útil más allá del 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

En el caso de 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 texto destacado perimetral: generador de URLs firmadas 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 puedas usar ninguna de las opciones recomendadas, ya que podría 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 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, tal 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 predeterminado para el tamaño de la carga útil de solicitud y 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 HTTPRequest.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 HTTPRequest.body.buffer.limit en el directorio /opt/apigee/edge-message- processor/conf y verifica qué valor se configuró con el siguiente comando: 
    grep -ri "HTTPRequest.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:HTTPRequest.body.buffer.limit=10m

  3. En el resultado de ejemplo anterior, observa que la propiedad HTTPRequest.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 asistencia del equipo de asistencia de Apigee, consulta Debes recopilar 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 413
  • Archivo de registro de las solicitudes a la API

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 413

  • 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