(Слабые) ETags и Last-Modified - PullRequest
Новая
       41

(Слабые) ETags и Last-Modified

19 голосов
/ 15 июня 2010

Насколько я понимаю спецификации, ETag, который был представлен в RFC 2616 (HTTP / 1.1), является преемником (своего рода) для Last-Modified-Header, который предлагает дать архитектору программного обеспечения больше управление процессом повторной проверки кэша.

Если присутствуют оба заголовка Cache-Validation-Headers (If-None-Match и If-Modified-Since), в соответствии с RFC 2616, клиент (т.е. браузер) должен использовать ETag при проверке, изменился ли ресурс , Согласно разделу 14.26 RFC 2616, сервер НЕ ДОЛЖЕН отвечать сообщением 304 Not Modified, если ETag, представленный в заголовке If-None-Match-Header, изменился, и сервер должен игнорировать дополнительный заголовок If-Modified-Since-Header , если представить. Если представленный ETag совпадает, он НЕ ДОЛЖЕН выполнять запрос, если только Дата в Last-Modified-Header не говорит об этом. (Если представленный ETag совпадает, сервер должен ответить 304 Not Modified в случае запроса GET или HEAD ...)

Этот раздел оставляет место для некоторых предположений:

  • Сильный ETag должен менять «каждый раз», ресурс меняется. Таким образом, необходимость ответить чем-то еще как 304 Not Modified на запрос с неизмененным ETag и If-Modified-Since-Header, доза которого не совпадает, является небольшим противоречием, потому что сильный ETag говорит, что ресурс был не модифицировано (Хотя это не так фатально, потому что сервер может снова отправить тот же неизмененный ресурс.)
  • ...

... хорошо Пока я писал это, вопрос сводился к следующему ответу:

(Небольшое) противоречие, изложенное выше, было сделано из-за слабых ETag. Ресурс, отмеченный Слабым ETag, мог измениться, хотя ETag не изменился. Таким образом, в случае слабого ETag было бы неправильно отвечать 304 Not Modified, если ETag не изменился, но дата, указанная в If-Modified-Since, не совпадает, верно?

1 Ответ

19 голосов
/ 16 июня 2010

Разница между обычным (сильным) ETag и слабым ETag заключается в том, что соответствующий сильный ETag гарантирует, что файл является байтовым идентичным, тогда как соответствующий слабый ETag указывает, что содержимое семантически одинаково. Поэтому, если содержимое файла изменяется, слабый ETag также должен измениться.

В представленном сценарии файл на сервере может быть новее, чем кэшированная копия на клиенте, но поскольку ETag совпадает, он семантически эквивалентен кэшированной копии, поэтому было бы приемлемо вернуть ответ 304 .

...