Entidad de solicitud demasiado grande 413 - TooBigBody

Estás consultando la documentación de Apigee Edge.
Consulta la documentación de Apigee X. Información

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 veas el siguiente mensaje de error: 

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

Causas posibles

Este error ocurre 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 .

A continuación, se muestran 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 supera 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 supera el límite permitido cuando la descomprime Apigee Edge. 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 la supervisión de la API, sigue estos pasos:

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

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

  3. Navega a la página Analyze > API Monitoring > Investigate.
  4. Selecciona el período específico en el que observaste los errores.
  5. Puedes seleccionar el filtro Proxy para acotar el código de falla.
  6. Traza el código de falla en función del valor Time.

  7. Selecciona una celda que contenga Fault Code protocol.http.TooBigBody y Status Code 413, como se muestra a continuación:

  8. Se muestra 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. Luego, en la ventana Registros, anota los detalles como se muestra a continuación :

    Sin comprimir

    Situación 1: La carga útil de la solicitud se envió sin comprimir

    En la ventana Registros, observa los siguientes detalles:

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

    Si Fault Source tiene el valor proxy, Fault Code tiene el valor protocol.http.TooBigBody y la Request Length es más de 10 MB, significa 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: La carga útil de la solicitud se envió en formato comprimido

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

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

    Si Fault Source tiene el valor proxy, Fault Code tiene el valor protocol.http.TooBigBody y Request Length es menor que 10 MB, significa que la solicitud HTTP del cliente tiene un tamaño de carga útil inferior al límite permitido en su formato comprimido, pero su tamaño es mayor que el límite permitido cuando Apigee no la comprime.

Trace

Para diagnosticar el error con la herramienta Trace, sigue estos pasos:

  1. Habilita la sesión de seguimiento y realiza una de estas acciones:
    • Espera a que ocurra el error 413 Request Entity Too Large o
    • 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 seguimiento.
  4. Navega a la fase Solicitud recibida del cliente (Request Received from Client).

    Sin comprimir

    Situación 1: La carga útil de la solicitud se envió sin comprimir

    Ten en cuenta la siguiente información:

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

    Comprimido

    Situación 2: La carga útil de la solicitud se envió en formato comprimido

    Ten en cuenta la siguiente información:

    • Codificación del contenido: gzip
    • Content-Length: 14969
    • Tipo de contenido: application/x-gzip
  5. Navega por las diferentes fases del seguimiento y localiza dónde ocurrió la falla.

  6. Por lo general, encontrarás el error en un flujo después de la fase Request Received from Client, como se muestra a continuación:

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

  8. Navega a Respuesta enviada al cliente y anota los valores del error del seguimiento. En el seguimiento de muestra que aparece a continuación, se 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 registrados de Analytics) en el seguimiento y haz clic en ella.

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

  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
    • El 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: Solicitud de carga útil sin comprimir

    Variable client.received.content.length: 15360204

    Comprimido

    Situación 2: Solicitud de carga útil en formato comprimido

    Variable client.received.content.length: 10489856

  12. En la siguiente tabla, se explica por qué Apigee muestra el error 413 en las dos situaciones según el valor de la variable client.received.content.length:
    Situación Valor de client.received.content.length Motivo de la falla
    Solicita carga útil en formato sin comprimir ~15 MB El tamaño es superior al límite permitido de 10 MB.
    Solicita la carga útil 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, sigue estos pasos:

  1. Si eres un usuario de la nube privada, puedes usar los registros de acceso de NGINX para determinar la información clave de los errores HTTP 413.

  2. Verifica los registros de acceso de NGINX:

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

  3. Busca para ver si hay errores 413 durante un período específico (si el problema ocurrió en el pasado) o si hay alguna solicitud que aún falla con 413.
  4. Si encuentras algún error 413 en el que X-Apigee-fault-code coincida con el valor deX-Apigee-fault-code , determina el valor de X-Apigee-fault-code

    Sin comprimir

    Situación 1 : Solicitud de tamaño de la carga útil 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-code

    Encabezados de respuesta Valor
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-sourc policy

    Ten en cuenta la longitud de la solicitud:15360440 (14.6 MB > límite permitido).

    Comprimido

    Situación 2 : Solicitud de tamaño de la carga útil 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-code

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

    Ten en cuenta el valor de Request Length: 15264 (14,900 < límite permitido)

    En esta situación, Apigee Edge muestra 413 aunque la longitud de la solicitud es menor que el límite permitido, ya que la solicitud se pudo haber enviado en formato comprimido y el tamaño de la carga útil supera el límite tras la descompresión 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 con fallas, la fuente de la falla y el tamaño de carga útil de la solicitud del error observado con la supervisión de la API, la herramienta de seguimiento o los registros de acceso de NGINX, como se explica en Pasos comunes de diagnóstico con la situación n.o 1 (sin comprimir).
  2. Si la fuente de errores tiene el valor policy o proxy, esto indica que el tamaño de la carga útil de la solicitud que envió la aplicación cliente a Apigee es mayor que el límite permitido en Apigee Edge.
  3. Verifica el Tamaño de carga útil de la solicitud como se determinó en el paso 1.
  4. También puedes validar si el tamaño de la carga útil de la solicitud supera el límite permitido de 10 MB. Para ello, verifica la solicitud real. Para ello, sigue estos pasos:
    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 pasada en la solicitud.
      2. Si descubres que el tamaño de la carga útil supera el límite permitido en Apigee Edge, entonces esa es la causa del problema.

        3. Solicitud de muestra:

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

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

Resolució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 descubre que el tamaño de la carga útil supera los 10 MB, el límite permitido, detiene la descompresión adicional y responde de inmediato con 413 Request Entity Too Large con el código de error protocol.http.TooBigBody.

Diagnóstico

  1. Determina el código con fallas, la fuente de errores y el tamaño de la carga útil de la solicitud para el error observado cuando usas la supervisión de la API, la herramienta de seguimiento o los registros de NGINX Access, como se explica en Pasos comunes de diagnóstico con la situación 2 (comprimida).
  2. Si la fuente de errores tiene el valor policy o proxy, esto indica que el tamaño de la carga útil de la solicitud que envió la aplicación cliente a Apigee es mayor que el límite permitido en Apigee Edge.
  3. Verifica el tamaño de carga útil de la solicitud como se determina en el paso 1.
    • Si el tamaño de la carga útil supera el 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, comprueba 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 el tamaño sin comprimir era mayor que el límite permitido mediante uno de los siguientes métodos:

    Trace

    Para validar mediante la herramienta Trace, sigue estos pasos:

    1. Si capturaste un seguimiento para la solicitud con errores, consulta los pasos que se detallan en Seguimiento y
      1. Determinar 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 solicitud Content-Encoding: gzip, esa es la causa del error.

    Solicitud real

    Para validar el uso de la solicitud real, sigue estos pasos:

    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 enviado en la solicitud.

      2. Comprueba si el tamaño descomprimido de la carga útil supera el límite permitido en Apigee Edge

        Ejemplo de solicitud:

        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 menor que el 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 algún 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 se establece en gzip.

    Registros de Message Processor

    Para validar el uso de los registros de Message Processor, haz lo siguiente:

    1. Si eres un usuario de la nube privada, puedes usar los registros de Message Processor para determinar la información clave de los errores HTTP 413.

    2. Verifica los registros de Message Processor:

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

    3. Busca para ver si hay errores 413 durante un período específico (si el problema ocurrió en el pasado) o si hay alguna solicitud que aún falla con 413.

      Puedes usar las siguientes strings 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, tan pronto como Message Processor determina que el total de bytes de lectura es superior a 10 MB, se detiene y, luego, imprime la siguiente línea: 
      Message is too large.  TotalRead 10489856 chunkCount 2570

      Implica que el tamaño de 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 falla como protocol.http.TooBigBody.

Resolución

Corregir tamaño

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 la solicitud o el tamaño de la carga útil por encima del límite permitido, según se define en la sección Límites.

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

    En el ejemplo anterior, para solucionar el problema puedes pasar un archivo más pequeño, por ejemplo, la 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 carga útil que supere el límite permitido, ve a las siguientes opciones.

Patrón de URL firmada

Opción 2 (recomendada]: Usa el patrón de URLs firmadas dentro de un JavaReferencia de Apigee

Para cargas útiles de más de 10 MB, Apigee recomienda usar un patrón de URL firmada dentro de un JavaReferencia de Apigee, como se ilustra en el ejemplo Edge Prompt: Signed URL Generator de GitHub.

Transmisión

Opción 3 : Usa la transmisión

Si tu proxy de API necesita manejar 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 permite aumentar el límite de tamaño de la carga útil de solicitudes y respuestas. Para obtener más información, consulta Cómo establecer el límite de tamaño del mensaje en el router o el procesador de mensajes.

Límites

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

  1. Si eres un usuario de la nube pública, el límite máximo de tamaño de la carga útil de solicitudes y respuestas es el que se documenta para Request/response size en Límites de Apigee Edge.
  2. Si eres un usuario de la nube privada, es posible que hayas modificado el límite predeterminado para el tamaño de la carga útil de solicitudes y respuestas (aunque no sea 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 Message Processor.

  1. En la máquina de Message Processor, busca la propiedad HTTPRequest.body.buffer.limit en el directorio /opt/apigee/edge-message- processor/conf y verifica qué valor se estableció 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 configuró con el valor 10m en http.properties.

    Esto indica que el límite del tamaño de la carga útil de la solicitud configurada en Apigee para la nube privada es de 10 MB.

Si aún necesitas asistencia de la 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 un usuario de la nube pública, proporciona la siguiente información:

  • Nombre de la organización
  • Nombre del entorno
  • Nombre del proxy de API
  • Completa el comando curl que se usa para reproducir el error 413
  • Archivo de seguimiento para las solicitudes a la API

Si eres un 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 seguimiento de las solicitudes a la API fallidas
  • Completa el comando curl 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: Se reemplazan ORG, ENV y PORT# por valores reales.

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