(Слабые) завершающие теги и измененный в последний раз
Насколько я понимаю спецификации, Завершающий тег, который был представлен в RFC 2616 (HTTP/1.1), является (своего рода) преемником к Last-Modified-Header, который является прочастично упорядоченным множеством, чтобы дать архитектору программного обеспечения больше контроля подтверждающим кэш процессом.
Если оба Заголовка проверки кэша (If-None-Match и If-Modified-Since) присутствуют, согласно RFC 2616, клиент (т.е. браузер) должен использовать Завершающий тег при проверке, если ресурс изменился. Согласно разделу 14.26 из RFC 2616, сервер не ДОЛЖЕН отвечать 304, Не Измененными, если Завершающий тег, представленный в If-None-Match-Header, изменился, и сервер должен проигнорировать дополнительный If-Modified-Since-Header, если существующий. Если представленный Завершающий тег соответствует, он не ДОЛЖЕН выполнять запрос, если Дата в Last-Modified-Header не говорит так. (Если представленный Завершающий тег соответствует, сервер должен ответить 304, Не Измененными в случае ПОЛУЧЕНИЯ - или ГЛАВНЫЙ запрос...),
Этот раздел оставляет комнату для некоторых предположений:
- Сильный Завершающий тег, как предполагается, изменяется ''каждый раз'', изменения ресурса. Так, необходимость ответить чем-то еще как 304 Не Измененный к запросу с неизменным Завершающим тегом и If-Modified-Since-Header, которому соответствует доза не, является определенным противоречием, потому что сильный Завершающий тег говорит, что ресурс не был изменен. (Хотя, это не то, что фатальный, потому что сервер может отправить тот же неизменный ресурс снова.)
- ...
... хорошо. В то время как я писал это, вопрос сводился к этому ответу:
(Маленькое) вышеизложенное противоречие, был сделан из-за Слабых Завершающих тегов. Ресурс, отмеченный со Слабым Завершающим тегом, возможно, изменился, хотя Завершающий тег не имеет. Так, в случае Слабого Завершающего тега это было бы неправильно, для ответа 304 Не Измененный, когда Завершающий тег не изменился, но дата, представленная в If-Modified-Since, не соответствует, правильно?
1 ответ
Разница между обычным (сильным) ETag и слабым ETag заключается в том, что соответствующий сильный ETag гарантирует, что файл побайтно идентичен, тогда как соответствующий слабый ETag указывает, что содержимое семантически одинаково. Поэтому, если содержимое файла изменится, слабый ETag также должен измениться.
В представленном вами сценарии файл на сервере может быть новее, чем кэшированная копия на клиенте, но поскольку ETag совпадает, он семантически эквивалентен кэшированной копии, поэтому было бы приемлемо вернуть ответ 304. .