HTTP 304 Not Modified en servidor: recurso no modificado

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

1. 1

   Comprobar las cabeceras condicionales enviadas en la petición GET o HEAD (If-None-Match / If-Modified-Since)

   Requiere herramientas

   Quién:

   Tú como desarrollador o administrador de sistemas inspeccionando las cabeceras de red del cliente.

   Cómo:

   Revisa la solicitud GET o HEAD que recibió el estado 304 para identificar qué cabeceras de validación añadió la caché del cliente o proxy (como If-None-Match o If-Modified-Since) y compáralas con el ETag o Last-Modified actual del recurso en el servidor.

   Resultado que importa:

   Verificas si la solicitud era efectivamente un GET o HEAD condicional con un validador coincidente.

   Si la petición incluía If-None-Match o If-Modified-Since coincidente con la versión vigente del recurso, confirma que la respuesta 304 Not Modified es el ahorro de transferencia previsto por RFC 9110 sección 15.4.5.

   Si el recurso sí había cambiado en el origen pero el servidor devolvió 304 ante el validador antiguo, confirma un fallo en la generación de ETag o Last-Modified en el servidor.

   Evidencia a conservar:

   Conserva las cabeceras de la solicitud condicional y las cabeceras de la respuesta 304 para compararlas.

   No manipules ni desactives globalmente el almacenamiento en caché ni la validación condicional en producción sin antes comparar los validadores ETag y Last-Modified.

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

2. 2

   Verificar que la respuesta 304 incluya las cabeceras exigidas por RFC 9110 y carezca de cuerpo

   Requiere herramientas

   Quién:

   Tú como persona desarrolladora o responsable de operaciones desde un cliente HTTP de prueba.

   Cómo:

   Examina la respuesta 304 generada por tu servidor o proxy para comprobar que termina al final de la sección de cabeceras sin contenido ni trailers y que incluye cualquiera de los campos Content-Location, Date, ETag, Vary, Cache-Control y Expires que habría enviado en una respuesta 200 (OK).

   Resultado que importa:

   Compruebas el cumplimiento estricto de los metadatos y del cierre sin cuerpo de la respuesta 304.

   Si el 304 incluye Date, ETag, Vary, Cache-Control/Expires y Content-Location (cuando procedan en un 200) y no envía cuerpo, confirma que el servidor cumple RFC 9110 sección 15.4.5.

   Si el servidor inyecta cuerpo en el 304 o suprime cabeceras obligatorias como ETag, Vary o Cache-Control, confirma un defecto de implementación en el servidor o intermediario.

   Evidencia a conservar:

   Guarda la salida en bruto de las cabeceras de una respuesta 200 y de una respuesta 304 al mismo recurso.

   Realiza las consultas de verificación únicamente con métodos seguros de lectura (GET o HEAD).

   Evidencia: RFC 9110 - HTTP Semantics

3. 3

   Confirmar cómo gestiona el cliente o el proxy compartido la reutilización de la representación almacenada

   Sin herramientas especiales

   Quién:

   Tú como desarrollador frontend/móvil o integrador del cliente HTTP.

   Cómo:

   Verifica si la petición condicional partió de la caché del navegador/cliente o de un proxy compartido intermedio, y comprueba que al recibir el 304 el cliente tome la representación guardada localmente como si fuera el contenido de un 200 (OK).

   Resultado que importa:

   Determinas si el fallo visible en la aplicación se debe a un cliente que rechaza códigos fuera de 2xx o que ignora su propia caché.

   Si el proxy compartido reenvía el 304 al cliente y este carga su representación almacenada sin error, descarta cualquier anomalía en el flujo de validación.

   Si tu código cliente envía manualmente If-None-Match sin disponer de la representación en caché o lanza excepción ante un 304 vacío, confirma que debes corregir el manejo del 304 en el cliente.

   Evidencia a conservar:

   Anota el fragmento del cliente HTTP o configuración del proxy donde se procesa la respuesta 304.

   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.4.5 de RFC 9110 e inscrito en el registro IANA dentro de la clase 3xx (Redirection), el estado HTTP 304 (Not Modified) indica que el servidor recibió una solicitud condicional GET o HEAD (por ejemplo, con cabeceras If-None-Match o If-Modified-Since) y redirige al cliente a reutilizar su representación ya almacenada como si fuera el contenido de una respuesta 200 (OK). El servidor que genera un 304 debe incluir los campos Content-Location, Date, ETag, Vary, Cache-Control y Expires que habría enviado en un 200, y la respuesta termina al final de la sección de cabeceras sin poder contener cuerpo ni trailers. Por sí solo, 304 nunca indica un fallo del servidor.

• Precauciónverificada con fuente

  No intentes enviar cuerpo ni trailers dentro de una respuesta HTTP 304: RFC 9110 sección 15.4.5 establece que toda respuesta 304 termina al concluir las cabeceras y cualquier dato extra corrompe el encuadre de mensajes.

  Evidencia: RFC 9110 - HTTP Semantics

• Seguroverificada con fuente

  No desactives por completo las cabeceras Cache-Control, ETag ni Vary para evitar respuestas 304 sin antes verificar qué validador envió el cliente en su petición condicional.

  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