http - (Débil) ETags y Last-Modified

if-modified-since

Question

Según entiendo las especificaciones, la ETag, que se introdujo en RFC 2616 (HTTP / 1.1) es una sucesora (de algún tipo) de la última cabecera modificada, que se propone dar al software-arquitecto más control sobre la Proceso de revalidación de caché.

Si ambos encabezados de validación de caché (If-None-Match y If-Modified-Since) están presentes, de acuerdo con RFC 2616, el cliente (es decir, el navegador) debe usar la ETag al verificar, si un recurso ha 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 Si-Ninguno-Coincidir ha cambiado, y el servidor tiene que ignorar un encabezado adicional Si-Modificado-Dado. , si está presente. Si el ETag presentado coincide, NO DEBE realizar la solicitud, a menos que la Fecha en el Encabezado de Última Modificación así lo indique. (Si el ETag presentado coincide, el servidor debe responder con un 304 No modificado en caso de una solicitud GET o HEAD ...)

Esta sección deja espacio para algunas especulaciones:

• Se supone que un ETag fuerte cambia "cada vez", el recurso cambia. Por lo tanto, tener que responder con algo más como 304 No modificado a una solicitud con un ETag sin cambios y un encabezado If-Modified-Since-Header, cuya dosis no coincida es un poco contradictoria, porque el ETag fuerte dice que el recurso era no modificado. (Sin embargo, esto no es tan grave, porque el servidor puede enviar el mismo recurso sin cambios nuevamente).
• ...

... ok Mientras escribía esto, la pregunta se reducía a esta respuesta:

La (pequeña) contradicción mencionada anteriormente, se hizo a causa de ETags débiles. Un recurso marcado con un ETag débil puede haber cambiado, aunque el ETag no lo haya hecho. Por lo tanto, en caso de un ETag débil, sería incorrecto responder con 304 No modificado, cuando el ETag no haya cambiado, pero la fecha presentada en If-Modified-Since no coincide, ¿verdad?

Answer 1

La diferencia entre un ETag regular (fuerte) y un ETag débil es que un ETag fuerte coincidente garantiza que el archivo sea idéntico byte a byte, mientras que un ETag débil coincidente indica que el contenido es semánticamente igual. 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 el ETag coincide, es semánticamente equivalente a la copia en caché, por lo que sería aceptable devolver una respuesta 304.