> И если отдать 304 на основании значения If-None-Match, то в кеше
> nginx'а будет оставлен потенциально устаревший ответ. Т.е.
> If-None-Match нужно просто убрать из рассмотрения при генерации
> ответа на бекенде, иначе корректной работы не добиться.

Дело в том, что изначально кеширования на бекенде, разрабатывалось для клиентского кеширования (в браузере), как уже писал не однократно, ревалидация происходит по If-None-Match, ревалидировать по заголовоку If-Modified-Since будет очень накладно, для больших сайтов, по этому мы сейчас используем Nginx кеширования на временной интервал. А там где контент завязан на пользователя, используется только клиентское (private) кеширования браузера.

Бекенд, не знает и не должен знать, какой тип кеша ему нужно ревалидировать, клиентский или кеш Nginx, по хорошему в первом и во втором случаи, механизм должен быть полностью одинаковым.

По этому чтобы иметь возможность использовать клиент кеширования, мы в конфиге прописали
fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty
Без этого работать с клиенским кешем невозможно, по причине удаления этих заголовком при включении fastcgi_cache_revalidate в Nginx.

Наша ошибка была в том, что бекенд приложения игнорировало отсутствия If-Modified-Since, но проводило ревалидацию при наличии If-None-Match и отвечало статусом 304 если ETag актуальный.
Мы это исправили добавив проверку на наличия If-Modified-Since.

Теперь все работает правильно, при клиент кешировании, мы в заголовок Cache-Control пишем дерективу private, это запретит Nginx кешировать данный ответ и таким образом он не попадет в кеш не при 200 статусе и так же ответ в 304 статусе в кеш не попадет.