¿Conoces algún uso práctico de If-Unmodified-Since in the wild? Desde el description, parece que este encabezado estaba destinado a ayudar a evitar las escrituras sucias. es decir, actualice este recurso solo si no se ha modificado desde la última hora modificada disponible con el cliente. A diferencia de If-Modified-Since, no parece ayudar con el almacenamiento en caché. ¿Me estoy perdiendo de algo?¿Cuál es el uso del encabezado HTTP If-Unmodified-Since?
Puedes usarlo p. Ej. para un range request.
ejemplo: su cliente solicita el recurso http://examp.le/foo?id=3 y la longitud del contenido es 4096 pero su cliente solo solicita los primeros 1024 bytes. Puede entonces (en un momento posterior) solicitar los 3072 bytes restantes, pero eso no tiene sentido si el recurso ha cambiado mientras tanto.
editar: También es posible que no desee cambiar/actualizar los datos si el recurso ha cambiado mientras tanto. P.ej. solicita un registro de cliente y edita algo. Si alguien más ha cambiado el registro mientras tanto, esto podría generar inconsistencias. Por lo tanto, envíe sus actualizaciones con un encabezado if-unmodified-since (-I-recuperado-los-datos) y el servidor web rechazará sus actualizaciones si el registro ya ha sido modificado; su cliente puede entonces solicitar los datos "en conflicto".
edit2: desde que ha pedido "cualquier uso práctico de If-Unmodified-Since in the wild": vea http://msdn.microsoft.com/en-us/library/dd179371.aspx#Subheading1.
Supongamos que tiene el primer requested the Blob properties. Ahora ya sabes, por ejemplo el tipo de contenido y la longitud del contenido (tal vez lo necesite para algún tipo de asignación). Alguien/algo puede cambiar el blob antes de enviar la segunda solicitud, Get Blob. Si envía el valor de Last-Modified como valor del encabezado If-Unmodified-Since, el servidor responderá con el código de error apropiado si el blob ha cambiado.
Supongamos que está desarrollando una aplicación que muestra el clima local para un lugar determinado. Si el servidor solo actualiza la información meteorológica solo 'x' veces al día, el navegador puede tener cuidado de no realizar una solicitud http dentro de ese marco de tiempo (incluso si hay una actualización).
Es útil al reanudar descargas grandes.
Es útil para múltiples solicitudes, realizadas durante un período de tiempo, pero relacionadas con un único recurso sin cambios.
Ejemplos:
las solicitudes de intervalo. La respuesta a la primera solicitud de rango (o quizás una preliminar HEAD) incluye el encabezado Last-Modified. Las solicitudes posteriores están destinadas solo a la misma versión de ese recurso. Si el recurso cambió entre el momento en que comenzamos la secuencia de solicitudes de rango y algún tiempo en el medio de la secuencia, queremos comenzar de nuevo.
Control de concurrencia optimista. Primero tenemos GET un recurso, realizamos algunos cambios en el lado del cliente y deseamos PUT el recurso actualizado. Pero solo queremos PUT el recurso actualizado siempre y cuando nadie más lo actualice mientras tanto. No queremos sobrescribir los cambios de nadie. Si resulta que alguien ha cambiado el recurso mientras tanto, queremos GET de nuevo, intenta volver a aplicar los cambios en el cliente (algo así como git rebase) e intente de nuevo PUT el recurso modificado.
Mi primer pensamiento fue simplemente "control de concurrencia". Buena captura sobre las solicitudes de rango! – rix0rrr
Es más adecuado para el control de concurrencia. No sé por qué esta respuesta tiene un voto tan alto, pero el encabezado de rango es más adecuado para las solicitudes de rango. p.ej. Rango: bytes = 1024- – sotn
@sotn El OP solicitó "uso práctico de If-Unmodified-Since in the wild", por lo que no proporcioné un concepto como respuesta sino 2.5 ejemplos de control de concurrencia. Pero tal vez tienes razón; agregará otro pequeño párrafo. – VolkerK