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

Question

Насколько я понимаю спецификации, 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, не совпадает, верно?

Answer 1

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

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