Last-Modified

Uso

La cabecera Last-Modified actúa como validador débil para las solicitudes condicionales. Cuando un cliente almacena en caché una respuesta que contiene Last-Modified, guarda la marca de tiempo y devuelve esa fecha en la cabecera de solicitud If-Modified-Since en las peticiones posteriores. El servidor compara la fecha almacenada con la hora de modificación actual del recurso. Si el recurso no ha cambiado, el servidor devuelve 304 Not Modified sin cuerpo. Si el recurso ha cambiado, el servidor envía la respuesta completa actualizada.

La cabecera If-Unmodified-Since utiliza la misma marca de tiempo para comprobaciones de condición previa en métodos no seguros como PUT y DELETE, y devuelve 412 Precondition Failed cuando el recurso se ha modificado desde la fecha indicada.

La fecha de Last-Modified es menos precisa que un ETag. Las marcas de tiempo tienen una granularidad de un segundo, por lo que los cambios producidos dentro del mismo segundo resultan invisibles para la validación basada en fechas. La cabecera ETag proporciona un validador más fuerte, vinculado al contenido exacto. Cuando en una respuesta están presentes tanto Last-Modified como ETag, el ETag tiene prioridad durante la revalidación.

El valor de fecha sigue el formato HTTP-date: nombre del día, día de dos cifras, mes abreviado, año de cuatro cifras, hora en horas, minutos y segundos, seguido de GMT. El formato es Weekday, DD Mon YYYY HH:MM:SS GMT.

Last-Modified: Fri, 04 Sep 1998 19:15:56 GMT

Nota

ETag es más preciso que Last-Modified. Los ETag detectan cualquier cambio, incluidas las modificaciones por debajo del segundo, mientras que Last-Modified tiene una granularidad de un segundo. Last-Modified está sujeto a la desviación de reloj entre servidores, mientras que los ETag basados en el hash del contenido son portables entre instancias con equilibrio de carga. Utilice ambas cabeceras juntas para lograr la máxima compatibilidad, ya que If-None-Match (ETag) tiene precedencia sobre If-Modified-Since cuando ambas están presentes.

Nota

La infraestructura de rastreo de Google admite Last-Modified e If-Modified-Since tal como los define el estándar de almacenamiento en caché de HTTP. La fecha de Last-Modified debe seguir el formato HTTP-date para evitar problemas de análisis. Establecer el campo max-age de la cabecera de respuesta Cache-Control al número de segundos durante los que se espera que el contenido permanezca sin cambios ayuda a los rastreadores a determinar cuándo volver a rastrear una URL. Por ejemplo, Cache-Control: max-age=94043.

Ejemplo

Una respuesta con la fecha de modificación del recurso. El cliente almacena esta marca de tiempo para futuras solicitudes condicionales.

Last-Modified: Wed, 01 Jun 2022 08:00:00 GMT

Un ciclo completo de solicitud condicional. El servidor envía Last-Modified con la respuesta inicial. En la siguiente solicitud, el cliente devuelve la marca de tiempo en If-Modified-Since. El servidor responde con 304 si el recurso no ha cambiado.

HTTP/1.1 200 OK
Last-Modified: Wed, 01 Jun 2022 08:00:00 GMT
Cache-Control: max-age=86400
Content-Type: text/html

Solicitud posterior:

GET /page HTTP/1.1
If-Modified-Since: Wed, 01 Jun 2022 08:00:00 GMT

Respuesta del servidor cuando no ha cambiado:

HTTP/1.1 304 Not Modified
Last-Modified: Wed, 01 Jun 2022 08:00:00 GMT
Cache-Control: max-age=86400

Una respuesta que combina Last-Modified con un ETag. El ETag proporciona un validador fuerte, mientras que la fecha de modificación ofrece una alternativa para los clientes que solo admiten la validación basada en fechas.

Last-Modified: Fri, 22 Nov 2024 14:30:00 GMT
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

Nota

Para obtener ayuda con SEO y almacenamiento en caché, póngase en contacto con los consultores SEO exempleados de Google Search Brothers.