Ладно, ничего, нашел соответствующую информацию в элементах управления проверкой и перезагрузкой кэша раздела HTTP Spec
По сути, вы можете обслуживать все нужные вам валидаторы, но вы должны знать, что в таких случаях прокси могут иметь набор разных валидаторов из своего собственного кэша и от различных пользовательских агентов, взаимодействующих с прокси. Они могут отправить вам один, и это может быть не самым правильным или самым оптимальным для конечных пользователей. Однако в спецификации был предложен «лучший подход».
Полагаю, это должно охватывать Expires заголовки, а также ETags, Cache-Control и еще много чего.
Вот соответствующая выдержка, если кому-то интересно:
Когда промежуточный кеш форсируется,
с помощью директивы max-age = 0, чтобы
повторно проверить свою собственную запись в кэше и
клиент поставил свой
валидатор в запросе, поставляемом
валидатор может отличаться от
Валидатор в настоящее время хранится с
запись в кеш. В этом случае кеш
МОЖЕТ использовать любой валидатор при создании
собственный запрос, не влияющий на семантику
прозрачность. Тем не менее, выбор
валидатор может повлиять на производительность.
Лучший подход для
промежуточный кеш, чтобы использовать свой собственный
валидатор при оформлении запроса. Если
сервер отвечает 304 (не
Доработано), то кеш можно вернуть
его теперь подтвержденная копия клиенту
с ответом 200 (ОК). Если
сервер отвечает с новой сущностью и
валидатор кэша, однако,
промежуточный кеш можно сравнить
вернул валидатор с одним
предоставляется в запросе клиента,
используя сильную функцию сравнения.
Если валидатор клиента равен
сервер-источник, затем
промежуточный кеш просто возвращает 304
(Не модифицировано). Иначе возвращается
новый объект с 200 (ОК)
ответ. Если запрос включает
директива no-cache, НЕ ДОЛЖНА
включают min-fresh, max-stale или
максимальный возраст.