Entidad de solicitud demasiado grande 413 - TooBigBody

Estás viendo la documentación de Apigee Edge.
Ve a 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, puedes observar 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 del 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 supera 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 se que el límite permitido en Apigee Edge. Usuarios perimetrales de nubes públicas y privadas
El tamaño de la carga útil de la solicitud supera el límite permitido después descompresión El tamaño de la carga útil que envía la aplicación cliente en formato comprimido como parte de HTTP supera el límite permitido cuando Apigee Edge la descomprime. Usuarios perimetrales de nubes públicas y privadas

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 API, haz lo siguiente:

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

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

  3. Navega a Analyze > 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 acotar el código de falla.
  6. Traza Código de error en Tiempo.

  7. Selecciona una celda que tenga el Código de error protocol.http.TooBigBody. Código de estado 413como se muestra a continuación:

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

  9. Haz clic en Ver registros y expande la fila de la solicitud con errores. Luego, en Logs, ten en cuenta los detalles como se muestra a continuación :

    Sin comprimir

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

    En la ventana Registros, observa los siguientes detalles:

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

    Si Fault Source tiene el valor proxy , el Fault Code tiene el valor protocol.http.TooBigBody y Request Length es superior a 10 MB, indica que la solicitud HTTP del cliente tiene un para solicitar un tamaño de carga útil mayor que el límite permitido en Apigee

    Comprimido

    Situación 2: Se envió la carga útil de la solicitud en forma comprimida

    En la ventana Registros, observa los siguientes detalles:

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

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

Trace

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

  1. Habilita la sesión de seguimiento y haz lo siguiente:
    • Espera a que se produzca el error 413 Request Entity Too Large.
    • Si puedes reproducir el problema, realiza la llamada a la API y reprodúcelo. 413 Request Entity Too Large error

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

  3. Selecciona una de las solicitudes fallidas y examina el seguimiento.
  4. Navega a la fase Solicitud recibida del cliente.

    Sin comprimir

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

    Ten en cuenta la siguiente información:

    • Content-Encoding: ausente
    • Duración del contenido: 15360204

    Comprimido

    Situación 2: Se envió la carga útil de la solicitud en forma comprimida

    Ten en cuenta la siguiente información:

    • Codificación del contenido: gzip
    • Duración del contenido: 14969
    • Content-Type: 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 del mensaje Solicitud recibida de Client, como se muestra a continuación:

  7. Anota 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 Response Sent to Client (Respuesta enviada al cliente) y anota los valores del error de la 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:
    • 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 tras la descompresión por parte de Apigee, cuando la carga útil se y se envían en formato comprimido. Siempre será el mismo que el valor de la política (10 MB) en este caso.

    Sin comprimir

    Situación 1: Solicita una carga útil sin comprimir

    Variable client.received.content.length: 15360204

    Comprimido

    Situación 2: Solicita una 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 basadas en el valor de la variable client.received.content.length:
    Situación Valor de client.received.content.length Motivo de la falla
    Carga útil de la solicitud en formato sin comprimir ~15 MB Tamaño > 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 un usuario de la nube privada, puedes usar los registros de acceso de NGINX para determinar la información clave sobre los errores 413 de HTTP.

  2. Verifica los registros de acceso de NGINX:

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

  3. Realiza una búsqueda para ver si hay algún error 413 durante una duración específica (si problema ocurrió en el pasado) o si todavía hay solicitudes que fallan 413
  4. Si encuentras algún error 413 con la coincidencia X-Apigee-fault-code el valor de protocol.http.TooBigBody y, luego, determina el valor del 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 muestra 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 Duración 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 Duración de la solicitud: 15264 (14.9 K < límite permitido)

    En esta situación, Apigee Edge muestra 413 a pesar de que La duración de la solicitud es menor que el límite permitido porque la solicitud puede se enviaron en formato comprimido y el tamaño de la carga útil supera el límite tras la descompresión por parte de Apigee Edge.

Causa: El tamaño de la carga útil de la solicitud supera el límite permitido

Diagnóstico

  1. Determina el Código de falla, Fuente del error y Tamaño de carga útil de la solicitud para el error observado cuando usas los registros de acceso de Supervisión de API, Herramienta de seguimiento o NGINX, como se explica en Pasos comunes del diagnóstico con la situación 1 (sin comprimir).
  2. Si la Fuente del error tiene el valor policy o proxy, este indica que el tamaño de la carga útil de la solicitud enviada por 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.
  4. También puedes validar si el tamaño de la carga útil de la solicitud en efecto es > Límite permitido de 10 MB por Verificar la solicitud real mediante los siguientes 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, realiza la los siguientes pasos:
      1. Verifica el tamaño de la carga útil pasada en la solicitud.
      2. Si observas que el tamaño de la carga útil es mayor que el en Apigee Edge, 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 ~15 MB. Si están usando otro cliente, obtener los registros del cliente para averiguar 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 está configurado como gzip, Apigee descomprime la solicitud. la carga útil útil. Durante el proceso de descompresión, si Apigee determina que el tamaño de la carga útil es mayor más de 10 MB el límite permitido, detiene la descompresión y responde de inmediato con 413 Request Entity Too Large con un 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 seguimiento o los registros de acceso de NGINX, como se explica en Pasos comunes del diagnóstico con la situación 2 (comprimido).
  2. Si la Fuente del error tiene el valor policy o proxy, entonces 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 la carga útil de la solicitud como se determina en el paso 1.
    • Si el tamaño de la carga útil > Límite permitido de 10 MB, esa es la causa del error.
    • Si el tamaño de la carga útil es < con un límite permitido de 10 MB, es posible que la solicitud la carga útil se pasan en formato comprimido. En este caso, comprueba el tamaño sin comprimir de la carga útil de solicitud comprimida.
  4. Puedes validar si la solicitud del cliente se envió en formato comprimido y el el tamaño sin comprimir superaba el límite permitido con una de las siguientes opciones métodos:

    Trace

    Para validar con la herramienta Trace, haz lo siguiente:

    1. Si has capturado un seguimiento de la solicitud errónea, consulta los pasos detallados en Trace y
      1. Determina el valor de la variable client.received.content.length
      2. Verifica si la solicitud del cliente contenía el objeto Content-Encoding: Encabezado gzip
    2. Si el valor de la variable client.received.content.length es mayor que el 10 MB, el límite permitido y el encabezado de la solicitud Content-Encoding: gzip, esa es la causa del 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, realiza la los siguientes pasos:
      1. Verifica el tamaño de la carga útil pasada en la solicitud junto con el Encabezado Content-Encoding enviado en la solicitud.

      2. Comprueba 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 del procesador de mensajes

    Para realizar la validación con 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 lo siguiente: la información clave sobre los errores 413 de HTTP.

    2. Revisa los registros de Message Processor:

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

    3. Realiza una búsqueda para ver si hay algún error 413 durante un período específico (si el problema en el pasado) o si todavía hay solicitudes que aún 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, tan pronto como el Message Processor determina el total bytes leídos es > 10 MB, se detiene e imprime 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 que Apigee arroja el error RequestTooLarge cuando el tamaño comienza a exceder el límite de 10 MB con el código de falla como protocol.http.TooBigBody

Solució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 un tamaño de solicitud o carga útil más de lo permitido. límite según se define en Límites.

  2. Si no son deseadas, modifica tu aplicación cliente para que envíe solicitudes o cargas útiles. inferior al límite permitido.

    En el ejemplo anterior, puede corregir el problema pasando un archivo más pequeño, Supongamos que tienes una carga útil 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 deseas 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 en un JavaAviso de Apigee

Para cargas útiles de más de 10 MB, Apigee recomienda usar un patrón de URL firmadas dentro de Apigee JavaLlamadas, ilustradas por el Leyenda perimetral: Generador de URL firmadas en GitHub.

Transmisión

Opción 3 : Usa la transmisión

Si tu proxy de API necesita manejar solicitudes o respuestas muy grandes, puedes habilitar streaming en Apigee.

CwC

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

Esta opción debe usarse solo cuando no puedas usar ninguna de las opciones recomendadas, ya que podría podrían presentar problemas de rendimiento si se aumenta el tamaño predeterminado.

Apigee proporciona un CwC que le permite aumentar el límite de tamaño de la carga útil de solicitud y respuesta. Para obtener más información, consulta Establece 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 cargas útiles superiores a el límite permitido 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 para la solicitud y la respuesta el tamaño de la carga útil 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 la configuración límite para el tamaño de la carga útil de las solicitudes y respuestas (aunque no es una práctica recomendada). Para determinar el límite máximo del tamaño de la carga útil de la solicitud, sigue las instrucciones 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 actualizó con un nuevo valor en Message Processor.

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

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

Si aún necesitas ayuda del equipo de asistencia de Apigee, ve a Se debe recopilar información de diagnóstico.

Se debe recopilar información de diagnóstico

Obtén 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
  • Completa el comando curl que se usa para reproducir el error 413
  • Archivo de seguimiento de 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 fallidas
  • Nombre de la organización
  • Nombre del entorno
  • Paquete de proxy de API
  • Archivo de registro de las solicitudes a la API con errores
  • 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: ORG, ENV y PORT# se reemplazan por valores reales.

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