Каково использование if-Unmodified-Since HTTP Header?

Знаете ли вы о каком-либо практическом использовании If-Unmodified-Since в дикой природе? Из описания кажется, что этот заголовок должен был помочь избежать нежелательной записи. то есть обновить этот ресурс, только если он не был изменен с момента последнего обновления, доступного клиенту. В отличие от If-Modified-Since, похоже, что это не помогает при кешировании. Я что-то пропустил?

Ответ 1

Вы можете использовать его, например. для запроса диапазона.
Например: ваш клиент запрашивает ресурс http://examp.le/foo?id=3, а длина содержимого - 4096, но ваш клиент запрашивает только первые 1024 байта. Затем он может (позднее) запросить оставшиеся 3072 байта, но это не имеет смысла, если ресурс изменился между тем.

edit: Также вы можете не захотеть изменять/обновлять данные, если ресурс изменился за это время. Например. вы запрашиваете запись о клиенте и что-то редактируете. Если кто-то другой изменил запись, тем временем это может привести к несоответствиям. Поэтому отправляйте свои обновления с заголовком if-unmodified-since (-I-retrieved-the-data), и веб-сервер будет/должен отклонять ваши обновления, если запись уже была изменена - ваш клиент может запросить "конфликтующие" данные.

edit2: так как вы просили "любое практическое использование If-Unmodified-Since in the wild": см. http://msdn.microsoft.com/en-us/library/dd179371.aspx#Subheading1.
Предположим, что вы сначала запросили свойства Blob. Теперь вы знаете, например. Content-type и Content-length (возможно, вам это нужно для своего рода выделения). Кто-то/что-то может изменить blob перед отправкой второго запроса Get Blob. Если вы отправите значение Last-Modified как значение заголовка If-Unmodified-Since, сервер ответит соответствующим кодом ошибки, если blob изменился.

Это примеры оптимистической блокировки/штампованной блокировки как средства управления concurrency, где значение последнего измененного заголовка служит в качестве защитного токена. См. https://en.wikipedia.org/wiki/Optimistic_concurrency_control

Ответ 2

Это полезно для нескольких запросов, проводимых в течение определенного периода времени, но относящихся к одному неизменному ресурсу.

Примеры:

Запросы диапазона. Ответ на запрос первого диапазона (или, возможно, предварительный HEAD) включает заголовок Last-Modified. Последующие запросы предназначены только для той же версии этого ресурса. Если ресурс изменился между тем, как мы начали последовательность запросов диапазона, и некоторое время в середине последовательности, мы хотим начать все заново.
Оптимистичный concurrency элемент управления. Сначала GET ресурс, сделаем некоторые изменения на стороне клиента и хотим PUT обновить ресурс. Но мы хотим только PUT обновить ресурс, пока никто не обновлял его за это время. Мы не хотим переписывать какие-либо изменения. Если окажется, что кто-то изменил ресурс тем временем, мы снова хотим его GET, попытаемся повторно применить изменения в клиенте (вроде как git rebase) и попробуйте PUT измененный ресурс еще раз.

Ответ 3

Это полезно при возобновлении больших загрузок.

Ответ 4

Предположим, вы разрабатываете приложение, которое показывает местную погоду для определенного места. Если сервер обновляет информацию о погоде только "x" раз в день, браузер может позаботиться о том, чтобы не сделать HTTP-запрос в течение этого временного интервала (даже если есть обновление).