HTTP 204 No Content: qué significa

Qué significa este error y cómo reconocerlo

• Un navegador, cliente de API, herramienta de monitorización o comprobador de sitios web informa de HTTP 204 No Content.
• Un navegador puede mostrar un resultado en blanco porque no hay cuerpo de respuesta que renderizar.
• Un cliente de API puede recibir un estado correcto sin JSON, HTML ni otra carga útil.
• DNS puede resolver y TLS puede completarse porque la solicitud llegó a un endpoint que habla HTTP.
• La respuesta puede afectar solo a una URL, un método HTTP, un estado de autenticación o un cliente.
• Las cabeceras de respuesta pueden revelar información sobre la caché, la autenticación, las redirecciones, los límites de velocidad o el proxy.

Causas principales, ordenadas por probabilidad

1. El endpoint utiliza intencionadamente 204 para un resultado correcto vacío. Algunas rutas completan una acción sin devolver una representación en el cuerpo de la respuesta.
2. El método de la solicitud o la ruta tienen un comportamiento de respuesta diferente. La misma ruta puede devolver estados distintos según si la solicitud es de lectura, actualización, eliminación u otra operación.
3. La aplicación completó la solicitud, pero no tiene contenido que devolver. Esto puede ser normal en un endpoint de acción o inesperado si el cliente necesita una carga útil.
4. Un proxy inverso, CDN, WAF o servidor web generó o transformó la respuesta. La configuración de la infraestructura puede producir un resultado diferente del comportamiento previsto por la aplicación.
5. La autenticación, el enrutamiento, la caché o una implementación reciente cambiaron la ruta de respuesta. Estas causas son más probables cuando el 204 es nuevo, se limita a determinados usuarios o afecta a varias rutas relacionadas.

Cómo solucionarlo

Para visitantes y usuarios de API

1. Reintenta la URL exacta una vez y confirma que la dirección sea correcta.
2. Anota el método HTTP utilizado por el cliente. Una ruta puede comportarse de forma diferente con distintos métodos.
3. Si el endpoint requiere una cuenta, inicia sesión normalmente y vuelve a intentarlo sin compartir credenciales ni datos de sesión.
4. Comprueba si el cliente espera un cuerpo de respuesta. Una respuesta 204 es correcta, pero no proporciona HTML, JSON ni otro cuerpo que mostrar.
5. Revisa las cabeceras de respuesta para obtener indicios sobre la autenticación, la caché, los límites de velocidad, las redirecciones o un servidor intermediario.
6. Si la respuesta vacía es inesperada, envía al propietario del sitio la URL, el método, la hora, el estado y las cabeceras saneadas. No incluyas contraseñas, cookies ni secretos de API.

Para propietarios de sitios y desarrolladores

1. Reproduce la solicitud exacta. Registra la URL, el método HTTP, el estado de autenticación, las cabeceras de respuesta y si el problema ocurre en uno o varios clientes.
2. Decide si el 204 es intencionado. Compara el comportamiento documentado de la ruta con la respuesta que espera el cliente. Si el cliente necesita datos, determina si el endpoint debería devolver una representación o si el cliente debería gestionar un resultado correcto vacío.
3. Identifica la capa que lo generó. Comprueba si el estado lo produjo la aplicación, el servidor web, el proxy inverso, la CDN o el WAF. Compara la respuesta del origen con la respuesta observada externamente solo cuando tengas autorización y puedas hacerlo de forma segura.
4. Inspecciona los registros correspondientes. Usa la hora, la ruta, el método y el identificador de solicitud, si está disponible, para encontrar el registro correspondiente de la aplicación o la infraestructura.
5. Compara los cambios recientes. Revisa los cambios en las implementaciones, el enrutamiento, la autenticación, la caché y la configuración del proxy y del WAF que puedan afectar a esta solicitud.
6. Aplica la corrección segura más específica. No desactives de forma general la autenticación, los controles de seguridad ni la caché para probar un único 204. Realiza cambios de configuración solo con la autorización adecuada y una vía de reversión conocida.
7. Vuelve a probar la misma solicitud. Confirma el estado, las cabeceras y el comportamiento del cliente; después, prueba las rutas y los métodos relacionados para asegurarte de que la corrección no haya provocado cambios no deseados.

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

• Monitoriza las tasas de estados HTTP por ruta, método e implementación, en lugar de tratar todas las respuestas 2xx como equivalentes.
• Documenta qué endpoints devuelven 204 intencionadamente y cómo deben gestionar los clientes una respuesta correcta vacía.
• Mantén las reglas de enrutamiento, autenticación, proxy, CDN, WAF y caché bajo control de versiones.
• Prueba las URL y los métodos de API importantes después de las versiones de la aplicación y la infraestructura.
• Conserva suficiente contexto saneado de las solicitudes y los registros del servidor para relacionar un estado con la capa responsable.
• Comprueba que los clientes no intenten analizar un cuerpo cuando una ruta está diseñada para devolver 204.

Preguntas frecuentes