В чем смысл If-Unmodified-Since/If-Modified-Since?Разве они не заменены ETags?

Question

Кажется, существует два различных способа реализации условных запросов с использованием заголовков HTTP, оба из которых можно использовать для кэширования, запросов диапазона, управления параллелизмом и т. д.:

1. If-Unmodified-Since и If-Modified-Since, где клиент отправляет временная метка ресурса.
2. Если изменено и если не изменено, где клиент отправляет ETag представление ресурса.

В обоих случаях клиент отправляет часть имеющейся у него информации о ресурсе, что позволяет серверу определить, изменился ли ресурс с тех пор, как клиент последний раз видел его.Затем сервер решает, выполнять ли запрос, в зависимости от условного заголовка, предоставленного клиентом.

Я не понимаю, почему доступны два отдельных подхода.Конечно, ETag заменяет временные метки, поскольку сервер может легко сгенерировать ETag из временных меток.

Итак, мои вопросы:

• В каких сценариях вы могли бы предпочесть If-Unmodified-Since/If-Modified-Since вместо ETags?
• В каких сценариях вам могут понадобиться оба?

Answer 1

Однажды я задумался об этом и понял, что есть одно отличие, которое весьма важно:Даты можно заказывать, ETags — нет.

Это означает, что если какой-то ресурс был изменен год назад, но никогда с тех пор, и мы это знаем.Тогда мы сможем правильно ответить на запрос If-Unmodified-Since для произвольных дат за последний год и согласиться, что конечно...с той даты он не менялся.

Etag можно сравнить только по идентичности.Либо это то же самое, либо нет.Если у вас есть тот же ресурс, что и выше, и в течение года корневой каталог документа был перемещен на новый диск и файловую систему, что дает всем файлам новые индексные дескрипторы, но сохраняет даты изменений.И кто-то основал ETags на номере индексного дескриптора файла.Тогда мы не можем сказать, что старый ETag все еще в порядке, не имея журнала прошлых, все еще в порядке, ETag.

Поэтому я не считаю, что одно из них устаревает другое.Они для разных ситуаций.Либо вы можете легко получить дату последнего изменения всех данных на странице, которую вы собираетесь обслуживать, либо вы можете легко получить ETag для того, что вы будете обслуживать.

Если у вас есть динамическая веб-страница с данными из множества поисков в базе данных, может быть сложно определить дату последнего изменения, не заставляя вашу базу данных содержать множество дат изменения.Но вы всегда можете сделать контрольную сумму md5 страницы, отображаемой в результате.

При поддержке этих протоколов кэширования я определенно выбираю только один из них, а не оба.

Answer 2

Есть одно довольно большое отличие:Я могу использовать ETag только в том случае, если я уже запрашивал его у сервера в прошлом.Временные метки, OTOH, я могу придумывать по ходу дела.

Answer 3

Простая причина:Обратная совместимость.