(Слабые) ETags и последнее изменение

Насколько я понимаю спецификации, 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 совпадает, он НЕ ДОЛЖЕН выполнять запрос, если это не указано в Date в заголовке Last-Modified-Header. (Если представленный ETag совпадает, сервер должен ответить 304 Not Modified в случае GET- или HEAD-запроса ...)

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

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

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

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


http last-modified etag if-modified-since
person Kai Moritz    schedule 15.06.2010    source источник
comment
ETags были введены в первой версии HTTP / 1.1, RFC 2068. И они не являются предшественниками Last-Modified.   -  person Julian Reschke    schedule 15.06.2010

Ответы (1)


arrow_upward
19
arrow_downward

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

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

person Marc Novakowski    schedule 16.06.2010
comment
Это может оказаться приемлемым. Но в разделе 14.26 RFC 2616 прямо указано, что сервер не должен;) Это была моя точка зрения, также известная как вопрос. И я думаю, ответ таков: ETag мог быть слабым. И в этом случае он мог быть изменен (более новая дата последнего изменения), хотя ETag - нет. - person Kai Moritz; 16.06.2010
comment
Правда. Я думаю, что если вам придется ошибиться, лучше всего будет ошибиться и снова подать файл. Это не повредит ничему, кроме необходимости передачи большего количества байтов по сети, и вы можете быть уверены, что у клиента установлена ​​последняя версия. - person Marc Novakowski; 16.06.2010