HTTP 413 Content Too Large: qué significa y cómo solucionarlo

Qué significa este error y cómo reconocerlo

• Un navegador, cliente de API, herramienta de carga o comprobación de monitorización recibe HTTP 413 Content Too Large.
• El error aparece al enviar un archivo grande, formulario, documento JSON, solicitud multipart u otro cuerpo de solicitud.
• Una versión más pequeña de la misma solicitud puede funcionar, mientras que la solicitud más grande falla.
• La respuesta puede proceder de un proxy, CDN, WAF, servidor web o aplicación, y puede tener encabezados o texto del cuerpo diferentes según la capa que la genere.
• El resto del sitio puede seguir disponible, y las URL o tipos de solicitud no relacionados pueden continuar funcionando.
• La resolución DNS y TLS pueden seguir funcionando correctamente, porque 413 es una respuesta de la capa HTTP.

Causas principales, ordenadas por probabilidad

1. La solicitud supera un límite de carga o de tamaño del cuerpo. La aplicación o el servidor web pueden imponer un tamaño máximo para el cuerpo de la solicitud, los archivos, los formularios o las solicitudes multipart.
2. Un intermediario tiene un límite inferior. Un reverse proxy, CDN, balanceador de carga o WAF puede rechazar la solicitud antes de que la aplicación de origen la reciba.
3. La solicitud se enruta a través de un endpoint más restrictivo. Distintas URL, métodos, hosts virtuales o entornos pueden tener políticas de tamaño diferentes.
4. Los límites de configuración no coinciden. El proxy puede permitir una solicitud que la aplicación rechaza, o la aplicación puede permitir una que el proxy bloquea.
5. La solicitud es más grande de lo esperado de forma no intencionada. La sobrecarga de multipart, un campo codificado demasiado grande, un archivo adjunto o un reintento del cliente con datos duplicados pueden aumentar el tamaño del cuerpo.
6. El endpoint rechaza intencionadamente el contenido grande. Algunas API o rutas de carga imponen un límite de producto o seguridad que no debe eliminarse sin confirmar la política prevista.

Cómo solucionarlo

Para visitantes y usuarios de API

1. Confirma la URL exacta y repite la solicitud una vez, sin actualizar la página repetidamente.
2. Si estás cargando un archivo, prueba con uno más pequeño o reduce su tamaño mediante un formato o método de compresión aprobado.
3. Para una solicitud de API, compara el payload que falla con un payload mínimo válido. Comprueba si hay campos inesperadamente grandes, datos incrustados, contenido duplicado o una construcción multipart incorrecta.
4. Confirma que la solicitud utiliza el método y el tipo de contenido previstos. No elimines la autenticación ni los controles de seguridad solo para evitar el error.
5. Si las solicitudes más pequeñas funcionan pero la solicitud necesaria no, envía al propietario del sitio la URL, el método, el tamaño aproximado de la solicitud, la marca de tiempo, los encabezados de respuesta y una descripción anonimizada del payload. No compartas contraseñas, cookies, tokens ni secretos de API.

Para propietarios de sitios y desarrolladores

1. Captura la solicitud que falla. Registra la URL, el método HTTP, el tipo de contenido, el tamaño aproximado del cuerpo, el estado, los encabezados de respuesta y si la solicitud pasa por un proxy, CDN, balanceador de carga o WAF. Oculta las credenciales y los datos personales.
2. Reproduce el problema comparando tamaños. Prueba una solicitud mínima válida y solicitudes progresivamente más grandes, o compara una carga correcta con la que falla. Esto ayuda a establecer el límite efectivo sin cambiar la configuración prematuramente.
3. Identifica la capa que la genera. Compara el cuerpo de la respuesta, los encabezados, los logs de acceso, los logs del proxy, los eventos del WAF y los logs de la aplicación correspondientes a la misma marca de tiempo y solicitud. Si la solicitud no aparece en los logs de la aplicación, es posible que un componente ascendente la haya rechazado antes.
4. Compara los límites a lo largo de la ruta. Comprueba los límites relevantes del cuerpo de la solicitud, de carga, multipart, proxy, CDN, WAF y aplicación. El límite efectivo lo controla el primer componente que rechaza la solicitud.
5. Elige la corrección más específica. Si la solicitud debe aceptarse, ajusta únicamente la ruta o el componente relevante después de confirmar la autorización y las implicaciones de memoria, almacenamiento, tiempo de espera y seguridad. Si el límite es intencionado, mantenlo y cambia el flujo de trabajo del cliente o documenta el máximo admitido.
6. Vuelve a probar el patrón de solicitud original. Usa el mismo método, URL, tipo de contenido y un tamaño de payload representativo. Confirma que una solicitud aceptada llega a la aplicación y que las solicitudes malformadas o claramente sobredimensionadas siguen gestionándose según lo previsto.
7. Comprueba el comportamiento relacionado. Prueba una solicitud más pequeña, una ruta no relacionada, el comportamiento de autenticación y cualquier otra capa de proxy o aplicación afectada por el cambio de configuración. Mantén el cambio bajo control de versiones y registra el límite final y el motivo.

Prevención y cómo verificar la solución

• Documenta los tamaños máximos admitidos para solicitudes, archivos y multipart en cada ruta de carga o API.
• Mantén visibles y, cuando sea posible, bajo control de versiones los límites de la aplicación, el servidor web, el proxy, la CDN y el WAF.
• Prueba tamaños límite y solicitudes grandes representativas en un entorno que no sea de producción antes del lanzamiento.
• Supervisa las respuestas 413 por ruta, método, cliente y despliegue para distinguir un aumento inesperado de un límite intencionado.
• Asegúrate de que los clientes validen el tamaño del archivo y del payload antes de la transmisión y ofrezcan una alternativa clara cuando una solicitud sea demasiado grande.
• Conserva suficientes logs anonimizados del proxy y la aplicación para determinar qué capa rechazó una solicitud, sin registrar secretos ni datos personales innecesarios.

Preguntas frecuentes