Re: Bug – 304 status - Cache-Control

[S.A.N]

> Торг здесь не уместен. Можно написать статью и без ревалидации по
> 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 кеширования и клиентское
кеширования.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,245951,246102#msg-246102