Согласно разделу 13.3.4 RFC 2616 , клиент HTTP 1.1 ДОЛЖЕН использовать ETag в любых условных запросах кеша, и если присутствуют оба ETag и Last Modified, он ДОЛЖЕН использовать оба. Заголовок ETag считается сильным валидатором (см. Раздел 13.3.3), если только сервер явно не объявил его слабым, в то время как заголовок Last Modified считается слабым, если между ним и заголовком Date не существует как минимум минутной разницы. Обратите внимание, однако, что Сервер также не обязан отправлять (но ДОЛЖЕН, если может).
Обратите внимание, что Клиент не проверяет заголовки, чтобы увидеть, изменились ли они; он просто слепо использует их в следующем условном запросе; Сервер должен оценить, отправлять ли запрошенный контент или ответ 304 Not Modified. Если Сервер отправляет только один, то Клиент будет использовать его один (хотя для запроса Range полезны только сильные валидаторы). Разумеется, на усмотрение промежуточных кэшей (если только им не было запрещено кэширование с помощью директив управления кэшем) и серверам указывается, как они будут действовать на заголовки; RFC заявляет, что они НЕ ДОЛЖНЫ возвращать 304 Not Modified, если валидаторы несовместимы, но поскольку значения заголовков генерируются сервером, у него есть немного свободы.
На практике я заметил, что Chrome, FireFox и IE 7+ отправляют оба заголовка, если они доступны. Я также проверил поведение при отправке модифицированных заголовков, что я уже подозревал из информации в RFC. Четыре проверенных клиента отправляли условные запросы только в том случае, если страницы обновлялись или это был первый раз, когда страница запрашивалась текущим процессом.