Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug ? 304 status - Cache-Control
- To: nginx-ru@xxxxxxxxx
- Subject: Re: Bug ? 304 status - Cache-Control
- From: "S.A.N" <nginx-forum@xxxxxxxx>
- Date: Tue, 07 Jan 2014 11:08:46 -0500
- Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=selenium.jlkhosting.com; s=x; h=Date:Sender:From:References:In-Reply-To:Message-ID:Content-Transfer-Encoding:Content-Type:Subject:To; bh=s2pdjIYbF6R0G0ZC7WeXjSKh/zNrtQ4PBdHTVm1FXHc=; b=Tk6uJjL/mAGsfr2e8Q0R9EsEzMfL7iQzEhRbSkYwt1Q/goy+zRg8njncH/nnUz/BJNcEOu6VB3c/WiUDj/LBqeABd/HFu/X2F8iBbxs4sPmNSi8Ijb8jdW2ivDaLxIuJDhC2aTeEpk98lbc8VoPSw2dmzC/A0VtKnf7udxZjoLE=;
- In-reply-to: <52CBFB87.8070502@csdoc.com>
- References: <52CBFB87.8070502@csdoc.com>
> Торг здесь не уместен. Можно написать статью и без ревалидации по
> 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
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru
|
