304 Not Modified

Se ha recibido una solicitud GET o HEAD condicional y habría resultado en una respuesta 200 OK si no fuera por el hecho de que la condición se evaluó como falsa.

En otras palabras, no hay necesidad de que el servidor transfiera una representación del recurso objetivo porque la solicitud indica que el cliente, que hizo la solicitud condicional, ya tiene una representación válida; el servidor por lo tanto está redirigiendo al cliente para que use esa representación almacenada como si fuera el contenido de una respuesta 200 OK.

El servidor que genera una respuesta 304 DEBE generar cualquiera de los siguientes campos de encabezado que hubieran sido enviados en una respuesta 200 OK a la misma solicitud: Cache-Control, Content-Location, Date, ETag, Expires, y Vary.

Dado que el objetivo de una respuesta 304 es minimizar la transferencia de información cuando el destinatario ya tiene una o más representaciones cacheadas, un remitente NO DEBERÍA generar metadatos de representación distintos de los campos listados arriba a menos que dichos metadatos existan con el propósito de guiar actualizaciones de caché (por ejemplo, Last-Modified podría ser útil si la respuesta no tiene un campo ETag).

Los requisitos en un caché que recibe una respuesta 304 están definidos en Sección 4.3.4 de RFC7234. Si la solicitud condicional se originó con un cliente saliente, como un agente de usuario con su propio caché enviando un GET condicional a un proxy compartido, entonces el proxy DEBERÍA reenviar la respuesta 304 a ese cliente.

Una respuesta 304 no puede contener un cuerpo de mensaje; siempre termina en la primera línea vacía después de los campos de encabezado.

• Source: RFC7232 Section 4.1