http - last - etag header exploit

¿Qué tiene prioridad: el ETag o el encabezado HTTP Last-Modified?

Question

Para dos solicitudes posteriores, ¿cuál de los dos encabezados siguientes tiene más peso para los navegadores si uno de ellos cambia: ETag o Last-Modified?

Answer 1

¿No es más como una expresión "O"? En pseudo código:

if ETagFromServer != ETagOnClient || LastModifiedFromServer != LastModifiedOnClient
GetFromServer
else
GetFromCache

Answer 2

=! 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 usar la versión actualmente ofrecida por el servidor; solo puede usar una versión almacenada en caché si es la misma. Por lo tanto, el servidor debe verificar la igualdad, no ''más nuevo''.

Answer 3

De acuerdo con RFC 2616 sección 13.3.4, un cliente HTTP 1.1 DEBE usar el ETag en cualquier solicitud de caché-condicional, y si están presentes tanto ETag como Last Modified, DEBERÍA usar 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 verifica 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, he notado que Chrome, FireFox e IE 7+ envían ambos encabezados, si están disponibles. 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.