(Débil) ETags y Last-Modified

Question

Por lo que entiendo las especificaciones, el ETag, que se introdujo en RFC 2616 (HTTP/1.1) es un sucesor (de géneros) para el último-Modified-Header, que es proponerle al software-arquitecto más control sobre el proceso de revalidación de caché.

Si están presentes ambos encabezados de validación de caché (If-None-Match y If-Modified-Since), de acuerdo con RFC 2616, el cliente (es decir, el navegador) debe usar ETag al verificar, si un recurso tiene cambiado De acuerdo con la sección 14.26 de RFC 2616, el servidor NO DEBE responder con un 304 no modificado, si el ETag presentado en un encabezado If-None-Match ha cambiado, y el servidor tiene que ignorar un If-Modified-Since-Header adicional. , si está presente. Si el ETag presentado coincide, NO DEBE realizar la solicitud, a menos que así lo indique la fecha en el último encabezado modificado. (Si la ETag presentado coincide, el servidor debe responder con un 304 Not Modified en caso de Get-o-CABEZA petición ...)

En esta sección se deja espacio para algunas especulaciones:

• Un fuerte Se supone que ETag cambiará '' cada vez '', el recurso cambia. Entonces, tener que responder con otra cosa como 304 Not Modified a una solicitud con un ETag sin cambios y un If-Modified-Since-Header, que dosis no coincide es un poco contradictorio, porque la fuerte ETag dice que el recurso fue no modificado. (Sin embargo, esto no es tan grave, debido a que el servidor puede enviar el mismo recurso sin cambios de nuevo.)
• ...

... visto bueno Mientras escribía esto, la pregunta se estaba reduciendo a esta respuesta:

La (pequeña) contradicción mencionada anteriormente, se debió a Weak ETags. Un recurso marcado con un ETag débil puede haber cambiado, aunque el ETag no ha cambiado. Entonces, en el caso de un ETag Débil estaría mal, responder con 304 No Modificado, cuando el ETag no ha cambiado, pero la fecha presentada en If-Modified-Since no coincide, ¿verdad?

Answer 1

La diferencia entre una ETag regular (fuerte) y una ETag débil es que una ETag fuerte coincidente garantiza que el archivo es idéntico byte por byte, mientras que una ETag débil coincidente indica que el contenido es semánticamente el mismo. Entonces, si el contenido del archivo cambia, la ETag débil también debería cambiar.

En el escenario que presenta, el archivo en el servidor puede ser más nuevo que la copia en caché en el cliente, pero dado que ETag coincide, es semánticamente equivalente a la copia en caché por lo que sería aceptable devolver un 304 respuesta.