HTTP 411 Length Required en servidor: falta Content-Length

Aviso: Sigue el orden documentado. Un código identifica el sistema afectado, pero por sí solo no demuestra qué pieza está averiada.

1. 1

   Verificar en la traza saliente si la petición incluye la cabecera Content-Length con un entero válido

   Requiere herramientas

   Quién:

   Tú como desarrollador o integrador del cliente HTTP, inspeccionando las cabeceras en bruto enviadas.

   Cómo:

   Comprueba en el registro de red si la solicitud que recibió el estado 411 Length Required incluye el campo de cabecera Content-Length, si su valor cumple la sintaxis decimal no negativa (1*DIGIT, sin signos ni unidades) o si el cliente envió Transfer-Encoding: chunked en su lugar.

   Resultado que importa:

   Confirmas si la cabecera Content-Length faltaba por completo o si el cuerpo se envió en modo chunked sin longitud previa.

   Si la petición POST o PUT carecía de Content-Length (por ejemplo, un POST sin cuerpo enviado sin Content-Length:

   0 o un stream sin tamaño precalculado), confirma la causa directa del 411 según RFC 9110 secciones 8.6 y 15.5.12.

   Si el cliente sí envió un Content-Length decimal exacto y aun así recibió 411, descarta una omisión en el cliente e indica comprobar si un proxy intermedio retiró la cabecera.

   Evidencia a conservar:

   Conserva las cabeceras exactas de la solicitud enviada y el cuerpo de la respuesta 411.

   No manipules el valor de Content-Length con una cifra inventada o distinta al tamaño real en octetos: una longitud inconsistente con el encuadre del mensaje provoca fallos de análisis o riesgos de seguridad.

   Evidencia: IANA HTTP Status Code Registry · RFC 9110 - HTTP Semantics

2. 2

   Calcular el tamaño exacto en octetos del cuerpo y repetir la petición añadiendo Content-Length

   Requiere herramientas

   Quién:

   Tú como persona desarrolladora de la aplicación cliente en un entorno de prueba.

   Cómo:

   Mide la longitud exacta en octetos (bytes codificados, no caracteres Unicode) del contenido de la solicitud, añade la cabecera Content-Length con ese número entero (o Content-Length: 0 si envías un POST vacío) desactivando el envío chunked sin longitud, y repite la solicitud una vez conforme a RFC 9110 sección 15.5.12.

   Resultado que importa:

   Verificas si el servidor acepta y procesa la solicitud cuando recibe el campo Content-Length definido.

   Si al incluir el Content-Length válido en octetos el servidor responde con éxito (2xx), confirma que el problema quedaba resuelto añadiendo la cabecera exigida.

   Si tras añadir un Content-Length exacto el servidor devuelve 413 Content Too Large, confirma que el servidor ya leyó la longitud pero el tamaño supera su límite admitido.

   Evidencia a conservar:

   Guarda la petición repetida con su cabecera Content-Length y el código de estado devuelto.

   Verifica que el recuento de Content-Length se calcule sobre los bytes finales tras cualquier codificación (como UTF-8 o compresión).

   Evidencia: RFC 9110 - HTTP Semantics

3. 3

   Comprobar si un proxy, CDN o pasarela intermedia elimina Content-Length al reenviar al origen

   Sin herramientas especiales

   Quién:

   Tú como administrador de sistemas u operador de infraestructura revisando las cabeceras en el borde y en el origen.

   Cómo:

   Compara las cabeceras de la solicitud recibida en el proxy inverso o pasarela con las cabeceras que llegan al servidor de origen para verificar si el intermediario transforma el cuerpo a Transfer-Encoding y suprime Content-Length.

   Resultado que importa:

   Identificas si el campo Content-Length se pierde en el salto entre el proxy y el servidor de origen.

   Si el cliente envía Content-Length al borde pero al servidor de origen llega sin Content-Length y este responde 411, confirma que la transformación del proxy intermedio origina el rechazo.

   Si la petición llega ya sin Content-Length al primer salto de entrada, confirma que la corrección corresponde exclusivamente al cliente emisor.

   Evidencia a conservar:

   Anota las cabeceras capturadas en la entrada del proxy y en la entrada del servidor de origen.

   Evidencia: RFC 9110 - HTTP Semantics

Un código solo tiene significado dentro del producto y la versión correctos.

Definido en la sección 15.5.12 de RFC 9110 e inscrito en IANA en la clase 4xx (Client Error), el código HTTP 411 (Length Required) señala que el servidor rechaza procesar la petición sin un campo de cabecera Content-Length definido (sección 8.6). Content-Length expresa la longitud de los datos de la representación como un entero decimal no negativo de octetos (1*DIGIT). RFC 9110 recomienda que el cliente envíe Content-Length cuando el método define significado para un contenido adjunto (como en un POST aunque valga 0) y no usa Transfer-Encoding. El cliente puede repetir la solicitud añadiendo un Content-Length válido. Por sí solo, 411 nunca demuestra una avería del servidor.

• Atención altaverificada con fuente

  No falsifiques nunca el valor de Content-Length ni desactives la validación de encuadre en proxies o servidores para evitar un HTTP 411: RFC 9110 sección 8.6 advierte que un Content-Length inconsistente con el encuadre recibido puede causar fallos de seguridad por contrabando de peticiones (request smuggling) o división de respuestas (response splitting).

  Evidencia: RFC 9110 - HTTP Semantics

• Seguroverificada con fuente

  No calcules Content-Length contando caracteres de una cadena de texto (`string.length`) cuando contenga caracteres multibyte UTF-8: mide siempre el número exacto de octetos del cuerpo final.

  Evidencia: RFC 9110 - HTTP Semantics

1. 1

   IANA HTTP Status Code Registry

   Internet Assigned Numbers Authority · 2025 · standard

2. 2

   RFC 9110 - HTTP Semantics

   IETF / RFC Editor · 2022 · standard