¿Cuál es el punto de Si-no modificado-Desde / If-Modified-Since? ¿No son reemplazadas por ETags?

Question

Parece que hay dos maneras distintas para poner en práctica las peticiones condicionales utilizando cabeceras HTTP, los cuales pueden ser utilizados para el almacenamiento en caché, las solicitudes de intervalo de control de concurrencia, etc ...:

1. Si-no modificado-Dado y If-Modified-Since , donde el cliente envía una marca de tiempo del recurso.
2. If-Modified y Si-Ninguno-Modified , donde el cliente envía un representación ETag del recurso.

En ambos casos, el cliente envía una pieza de información que tiene sobre el recurso, que permite al servidor para determinar si el recurso ha cambiado desde que el cliente vio por última vez. Después, el servidor decide si va a ejecutar la solicitud en función de la cabecera condicional suministrado por el cliente.

No entiendo por qué dos enfoques separados están disponibles. Seguramente, ETags sustituyen las marcas de tiempo, ya que el servidor podría fácilmente elegir generar ETags de marcas de tiempo.

Por lo tanto, mis preguntas son:

• ¿En qué escenarios puede ser que usted a favor de Si-no modificado-Desde / If-Modified-Since sobre ETags?
• ¿En qué escenarios podrías tener ambos?

Answer 1

Una vez reflexionó sobre la misma cosa, y se dio cuenta de que hay una diferencia que es bastante importante: Las fechas pueden ser ordenados, ETags no puede.

Esto significa que si algún recurso se modificó hace un año, pero nunca desde entonces, y lo conocemos. Entonces podemos contestar correctamente una el último año-Si-no modificado Desde solicitud de fechas arbitrarias y acepta que seguro ... que ha sido modificado desde esa fecha.

Un Etag sólo es comparable a la identidad. O bien es el mismo o no lo es. Si tiene el mismo recurso que el anterior, y durante el año de la docroot se ha trasladado a un nuevo disco y sistema de archivos, dando todos los archivos nuevos ínodos pero conservando fechas de modificación. Y alguien había basado en los ETags número de inodo del archivo. Entonces no podemos decir que el viejo ETag todavía está bien, sin tener un registro del pasado-aún-okay-ETags.

Así que no los veo como uno obsoleto a otro. Son para diferentes situaciones. O se puede conseguir fácilmente una fecha Modified-Último de todos los datos en la página que está a punto de servir, o se puede obtener fácilmente una ETag para lo que va a servir.

Si usted tiene una página web dinámica con datos de una gran cantidad de operaciones de búsqueda de base de datos que podría ser difícil decir cuál es la fecha de modificación, es pasado sin hacer que su base de datos contienen gran cantidad de fechas de modificación. Pero siempre se puede hacer una suma de control MD5 de la página representada resultado.

Al apoyar estos protocolos de caché que sin duda alguna para sólo uno de ellos, nunca las dos cosas.

Answer 2

Hay una diferencia bastante grande: Sólo puedo usar ETags si ya he pedido al servidor para uno en el pasado. Las marcas de tiempo, otoh, que puede compensar a medida que avanzo.

Answer 3

sencilla razón:. Compatibilidad hacia atrás