HTTP 304 Not Modified: qué significa

Qué significa este error y cómo reconocerlo

• Las herramientas de desarrollo del navegador, un cliente de API, una herramienta de monitorización o un comprobador informan del estado 304 Not Modified.
• La respuesta contiene cabeceras de caché o validadores, pero no un cuerpo del recurso.
• Un navegador puede mostrar la página con normalidad porque reutiliza su representación almacenada en caché.
• Un cliente de API o un comprobador puede parecer recibir una respuesta vacía si no implementa correctamente la caché condicional.
• El resultado puede aplicarse a una URL o recurso concreto, no a todo el sitio web.
• DNS y TLS pueden seguir funcionando porque el cliente llegó a un endpoint HTTP y recibió una respuesta HTTP.

Causas principales, ordenadas por probabilidad

1. El cliente envió una solicitud condicional. Las cabeceras de solicitud como If-None-Match o If-Modified-Since preguntaron si la representación almacenada en caché seguía estando actualizada.
2. El recurso no ha cambiado. El servidor o un intermediario coincidió con el validador proporcionado, como un valor ETag o Last-Modified, y devolvió correctamente 304.
3. Un navegador, proxy o CDN realizó una validación normal de la caché. La respuesta puede haber sido generada por un intermediario en lugar de la aplicación de origen.
4. Un cliente o una herramienta de monitorización mostró una respuesta de caché normal como si fuera un error. Algunas herramientas están configuradas para esperar un cuerpo de respuesta completo y puede que no reutilicen su copia almacenada.
5. La configuración de validadores o de caché es incoherente. Pueden producirse resultados inesperados cuando los despliegues de la aplicación, las reglas del proxy o las cabeceras de origen generan validadores de caché obsoletos, contradictorios o demasiado amplios.

HTTP 304 no es, por sí mismo, una redirección, un fallo de autenticación, una respuesta de límite de solicitudes ni una interrupción del servidor. Estas condiciones deben confirmarse a partir del estado real, las cabeceras y los logs, no inferirse de 304.

Cómo solucionarlo

Para visitantes

1. Deja que el navegador gestione primero la respuesta. Un navegador normal debería usar su copia almacenada en caché al recibir 304. Si la página aparece correctamente, normalmente no es necesario hacer nada.
2. Comprueba la URL exacta. Confirma el hostname, la ruta, la cadena de consulta y el protocolo. Distintas URL pueden tener representaciones almacenadas en caché independientes.
3. Vuelve a intentarlo una vez si el contenido mostrado está obsoleto o incompleto. Usa los controles de recarga normales del navegador en lugar de actualizar repetidamente.
4. Compara con otro cliente solo cuando sea útil. Si un navegador muestra contenido obsoleto y otro no, registra la URL afectada, la hora aproximada y el comportamiento del cliente para el propietario del sitio.
5. Contacta con el propietario del sitio si el recurso no se puede cargar. Informa de la URL y la marca de tiempo, pero no compartas contraseñas, cookies, cabeceras de autorización ni otros datos privados.

Para desarrolladores y propietarios de sitios

1. Captura todo el contexto de la solicitud y la respuesta. Registra el método HTTP, la URL completa incluidos los parámetros de consulta relevantes, el estado, los validadores de la solicitud, los validadores de la respuesta, Cache-Control, Vary y cualquier cabecera del proxy o CDN. Elimina las credenciales y los datos personales antes de compartirlos.
2. Confirma que la solicitud es condicional. Busca If-None-Match o If-Modified-Since. Un 304 normalmente es significativo cuando el cliente tiene una representación almacenada en caché que validar.
3. Comprueba la capa que produce la respuesta. Determina si el 304 provino del navegador, de un proxy local o compartido, de una CDN, de un reverse proxy, del servidor web o de la aplicación. Cuando estén disponibles, usa el identificador de solicitud y la marca de tiempo de ese componente.
4. Compara los validadores con el recurso. Verifica que ETag o Last-Modified representen correctamente la representación solicitada y que la negociación de contenido esté cubierta por una política Vary adecuada cuando corresponda.
5. Prueba una solicitud no condicional cuando necesites el cuerpo actual. Usa un cliente de diagnóstico autorizado o elimina temporalmente las cabeceras de solicitud condicionales en una prueba controlada. Es una comparación de solo lectura, pero sigue los controles de acceso normales del servicio y evita enviar cabeceras sensibles a herramientas que no sean de confianza.
6. Revisa los cambios recientes de caché y despliegue. Comprueba las versiones de la aplicación, la generación de recursos, las reglas del proxy o CDN, la compresión y la negociación de contenido, el enrutamiento y el comportamiento de invalidación de caché. Céntrate en los cambios que afectan a la ruta específica en lugar de cambiar inmediatamente la configuración global.
7. Aplica la corrección segura más específica. Corrige el validador, la política de caché o la regla del intermediario solo después de identificar la discrepancia. Evita desactivar la caché globalmente cuando el problema afecta a una sola ruta o representación.
8. Vuelve a probar la misma ruta de solicitud. Prueba tanto una solicitud condicional como una solicitud nueva y confirma que las rutas y los métodos de solicitud relacionados sigan devolviendo los estados y las representaciones previstos.

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

• Trata 304 como un resultado esperado de validación de caché en la monitorización, salvo que el cliente no pueda usar su representación almacenada.
• Prueba las rutas importantes con solicitudes normales y condicionales después de los despliegues.
• Mantén intencionado y documentado el comportamiento de ETag, Last-Modified, Cache-Control y Vary.
• Asegúrate de que los validadores de caché cambien cuando cambie la representación servida, incluidas las variantes relevantes de la negociación de contenido.
• Monitoriza las tasas de estados por ruta y por capa de caché para distinguir un patrón inesperado de 304 del tráfico normal de los navegadores.
• Mantén bajo control de versiones, cuando sea práctico, la configuración del proxy, la CDN, el servidor web y la aplicación.
• Conserva durante el tiempo suficiente los identificadores de solicitud y las marcas de tiempo saneados para poder asociar un informe con la capa que generó la respuesta.

Preguntas frecuentes