Para dos solicitudes posteriores, ¿cuál de los siguientes dos encabezados tiene más peso para los navegadores si uno de ellos cambia: ETag o Last-Modified?¿Qué tiene prioridad: el ETag o el encabezado HTTP Last-Modified?
¿No es más bien una "O" expresión. En pseudo código:
if ETagFromServer != ETagOnClient || LastModifiedFromServer != LastModifiedOnClient
GetFromServer
else
GetFromCache
Según RFC 2616 sección 13.3.4, un cliente HTTP 1.1 debe utilizar el ETag en cualquier solicitud de caché-condicional, y si tanto un ETag y la última modificación están presentes, es conveniente utilizar ambos. El encabezado ETag se considera un validador fuerte (consulte la sección 13.3.3), a menos que el servidor lo declare débil explícitamente, mientras que el encabezado Última modificación se considera débil a menos que exista al menos una diferencia de un minuto entre este y el encabezado Fecha. Sin embargo, tenga en cuenta que el Servidor no está obligado a enviar ninguno (pero DEBERÍA, si puede).
Tenga en cuenta que el cliente no comprueba los encabezados para ver si han cambiado; simplemente los usa ciegamente en la próxima solicitud condicional; corresponde al servidor evaluar si se envía el contenido solicitado o una respuesta 304 no modificada. Si el servidor solo envía uno, entonces el cliente lo usará solo (aunque solo los validadores fuertes son útiles para una solicitud de rango). Por supuesto, también está a discreción de los cachés intermedios (a menos que se haya evitado el almacenamiento en caché a través de las directivas de control de caché) y del servidor en cuanto a cómo actuarán sobre los encabezados; el RFC declara que NO DEBE devolver un 304 No modificado si los validadores son inconsistentes, pero dado que el servidor genera los valores del encabezado, tiene bastante libertad de acción.
En la práctica, me he dado cuenta de que Chrome, Firefox e IE 7+ toda envían tanto a la cabecera, si está disponible. También probé el comportamiento al enviar encabezados modificados, que ya sospechaba de la información en el RFC. Los cuatro clientes que probé solo enviaron solicitudes condicionales si las páginas se actualizaron o si era la primera vez que el proceso actual solicitaba la página.
Gran respuesta, Thomas. Gracias por proporcionar las especificaciones oficiales y discutir las implementaciones de navegador actuales. – dthrasher
Citando de la sección 14.26, ** el servidor NO DEBE realizar el método solicitado, a menos que sea necesario porque la fecha de modificación del recurso no coincide con la proporcionada en un campo de encabezado If-Modified-Since en la solicitud. ** como If-Modified-Since tiene prioridad. – Vicary
=! es el operador de comparación correcto. El cliente debe mantener la cadena literal recibida del servidor, ya que las conversiones pueden crear pequeñas diferencias. No puede suponer que 'más nuevo es mejor'.
¿Por qué? Considere el caso donde el operador del servidor revierte una versión incorrecta de un recurso. La versión revertida es MAYOR, pero correcta.
El cliente debe utilizar la versión actualmente ofrecido por el servidor; solo puede usar una versión en caché si es la misma. Por lo tanto, el servidor debe verificar la igualdad, no 'más nuevo'.
Creo que la última marca de tiempo modificado se debe comparar de manera diferente, como en: si ETagFromServer = ETagOnClient ||! LastModifiedFromServer> LastModifiedOnClient – RoyM
Es una instrucción AND porque la ETag puede ser débil, en cuyo caso podría tener una entidad semánticamente equivalente y luego recurrir al último encabezado modificado. Considere una situación en la que una imagen podría ser recodificada y queremos decir que el original y la recodificación son los mismos a pesar de que no son idénticos en el byte. En este caso, queremos utilizar la última modificación como una alternativa y es por eso que AMBOS deben ser consistentes – ParoX