> Торг здесь не уместен. Можно написать статью и без ревалидации по
> ETag.
>
> Как реализовать ревалидацию по ETag, если его просто не будет у части
> клиентов. В кеше ведь всегда находится только один вариант контента -
> или сжатый gzip, или uncompressed. А в кешах у клиентов - в общем
> случае
> встречаются оба этих варианта. Делать ревалидацию по If-None-Match
> потом будет только та половина клиентов, которой больше повезло.

Я не планировал торговаться, дело в том что я программист не администратор и хотел бы написать статью в первую очередь для программистов, в статье раскрыть проблемы создания эффективных валидаторов кеша, на данный момент самый эфективный валидатор это ETag, мы его используем не только как валидатор, но как прелоадер ключей к Memcache, но это разговор на целую статью.
Без ETag статья про кеширования будет просто не интересна, писать шпаргалки для амдинов на тему как настроить кеширования Nginx на временной интервал, с последующей ревалидацией по IF-Modified-Since, как-то совсем грустно потому что на дворе уже 2014 г.

> > Но это далекое будущее, сейчас меня больше интересует почему тот же
> Squid
> > прокси не удаляет клиенские заголовки кеширования и сам не кешит
> ответ в 304
> > статусе и это все без спец конфига под каждый сайт :)
>
> squid - это forward proxy, а nginx - web server. что ж тут не
> ясного...

Для меня как для разработчика, важен момент прозрачной работы всех звений между приложением и клиентом, когда одно звено (Nginx) начинает удалять клиентские заголовки кеширования, это уже не прозрачное проксирования, это уже магия хаков, возможно оправданных, потому что таким образом Nginx форсирует наполнения своего кеша и защищает себя от проблемы кеширования 304 статуса, но то что это исключает возможность бекенда работать с клиенским кешированиям во внимания никто не брал, наверно дело в том что не многие одновременно на одном server{} используют Nginx кеширования и клиентское кеширования.