413 Content Too Large

Uso

Cuando se recibe el mensaje de error 413 Content Too Large, el cliente está enviando un cuerpo de solicitud demasiado grande para el servidor. Un ejemplo habitual es el de un cliente que intenta enviar un archivo de tipo y formato aceptables, pero cuyo tamaño supera el límite. Las imágenes, por ejemplo, suelen tener una resolución innecesariamente alta y ocupan bastante menos sin afectar al uso previsto. En lugar de asumir la responsabilidad de modificar los archivos de imagen, el servidor rechaza la transferencia y confía en que el cliente haga el procesamiento necesario.

En estas situaciones, el cliente comprueba por adelantado si el tamaño del archivo está permitido, antes de iniciar el PUT, mediante la cabecera Expect: 100-continue. El servidor lo confirma y, en función de la respuesta, el cuerpo del mensaje se envía o se retiene.

El servidor envía opcionalmente una cabecera Retry-After en la respuesta. Si está presente, el cliente vuelve a intentar la solicitud tras un periodo determinado o en una fecha y hora concretas. Por ejemplo, si el cliente ha superado la cuota de subida de la semana, o si no se permiten subidas grandes en horas punta, el servidor sugerirá intentarlo de nuevo en un momento más adecuado.

Si la situación se produce porque el servidor se ha quedado sin espacio de almacenamiento, entonces el servidor envía 507 en su lugar.

El servidor incluye la cabecera Connection: close para terminar la conexión, de modo que el cliente no llegue a enviar el cuerpo del mensaje.

Nota

Los WAF y los cortafuegos de CDN (Cloudflare, AWS WAF) aplican límites de tamaño del cuerpo con independencia del servidor de origen. Revise los registros del WAF o del cortafuegos si el límite del servidor de origen es superior a la carga útil. Opciones para reducir el tamaño de la carga útil: comprimir con Content-Encoding: gzip, implementar paginación para conjuntos de resultados grandes y usar subidas multiparte o reanudables para archivos grandes.

Impacto en SEO

Los motores de búsqueda como Google no indexarán una URL con un estado de respuesta 413. Las URL indexadas previamente se eliminarán de los resultados de búsqueda.

Ejemplo

El cliente intenta enviar un archivo y el servidor responde con 413 Content Too Large porque en ese momento hay mucho tráfico. El servidor deniega la solicitud, cierra la conexión y sugiere al cliente que lo intente de nuevo pasados 30 minutos.

Solicitud

PUT /docs HTTP/1.1
Host: example.com
Content-Type: application/pdf
Content-Length: 10000

Respuesta

HTTP/1.1 413 Content Too Large
Retry-After: 1800
Connection: close
Content-Type: text/html
Content-Length: 188

<html>
  <head>
    <title>File Too Large</title>
  </head>
  <body>
   <p>Too much server traffic to accept the transfer
   at this time. Try again after 30 minutes.</p>
  </body>
</html>

Cómo solucionarlo

El error procede de la capa de la pila que aplica primero un límite de tamaño: servidor web, proxy inverso, CDN o framework de la aplicación. Identifique la capa que devuelve el 413 y ajuste el límite allí.

nginx: configure client_max_body_size en el bloque http, server o location. Un valor de 0 desactiva la comprobación por completo (no recomendado en producción). Reinicie nginx tras cambiar el valor.

Apache: configure LimitRequestBody en httpd.conf o en .htaccess. El valor se expresa en bytes, por lo que 10 MB son 10485760. Recargue Apache para aplicarlo.

IIS: edite el atributo maxAllowedContentLength en el archivo web.config bajo system.webServer > security > requestFiltering > requestLimits.

PHP: ajuste tanto upload_max_filesize como post_max_size en php.ini. El valor de post_max_size debe ser igual o mayor que upload_max_filesize.

Node.js / Express: configure la opción limit en body-parser o en el middleware JSON/URL-encoded integrado de Express, por ejemplo express.json({ limit: ‘50mb’ }).

Cloudflare: los planes Free y Pro limitan las subidas a 100 MB, Business a 200 MB y Enterprise a 500 MB. Las subidas que superan estos límites devuelven 413 antes de llegar al origen. Para subidas de archivos grandes detrás de Cloudflare, omita el proxy o utilice estrategias de subida por fragmentos.

En el lado del cliente, comprima o fragmente las cargas útiles grandes antes de enviarlas. Para las subidas de archivos, implemente protocolos de subida multiparte o reanudable para mantenerse dentro de los límites del servidor. Utilice el mecanismo Expect: 100-continue para comprobar si el servidor aceptará el tamaño de la carga útil antes de transmitir el cuerpo completo.

Referencias de código

.NET

HttpStatusCode.RequestEntityTooLarge

Rust

http::StatusCode::PAYLOAD_TOO_LARGE

Rails

:payload_too_large
:request_entity_too_large

http.StatusRequestEntityTooLarge

Symfony

Response::HTTP_REQUEST_ENTITY_TOO_LARGE

Python3.5+

http.HTTPStatus.REQUEST_ENTITY_TOO_LARGE

Java

java.net.HttpURLConnection.HTTP_ENTITY_TOO_LARGE

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_REQUEST_TOO_LONG

Angular

@angular/common/http/HttpStatusCode.PayloadTooLarge