Насколько я понимаю спецификации, 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, изменился, и сервер должен игнорировать дополнительный If-Modified-Since-Header, если имеется. Если представленный ETag соответствует, он НЕ ДОЛЖЕН выполнять запрос, если это не говорит о дате в последнем измененном заголовке. (Если представленный ETag соответствует, сервер должен ответить 304 Not Modified в случае запроса GET- или HEAD...)
В этом разделе есть место для некоторых размышлений:
- Ожидается, что сильный ETag изменится "каждый раз", ресурс изменится. Поэтому, чтобы ответить на что-то еще, как 304 Не изменено на запрос с неизменным ETag и If-Modified-Since-Header, какая доза не соответствует, является немного противоречием, потому что сильный ETag говорит, что ресурс был не модифицировано. (Хотя, это не так роковое, потому что сервер может снова отправить тот же неизменный ресурс.)
- ...
... o.k. Пока я писал это, вопрос сводился к этому ответу:
Указанное выше (небольшое) противоречие было сделано из-за слабых ETags. Ресурс, отмеченный слабым ETag, возможно, изменился, хотя ETag не имеет. Таким образом, в случае слабого ETag было бы неправильно ответить 304 Not Modified, когда ETag не изменился, но дата, представленная в If-Modified-Since, не соответствует, правильно?
