Юрий,
Если нужно заместить элемент, то даже отдельный location не потребуется:
geo $bypass {
192.168.0.0/24 1;
default 0;
}
И потом:
location / {
proxy_cache zone1;
proxy_pass $upstream;
proxy_cache_bypass $bypass;
}
В таком варианте, при обращении из 192.168.0.0/24 обращение в upstream
будет мимо кэша. Но при этом, контент будет обновлён, если ответ в
принципе может быть кэширован.
Добавить в условие заголовки так же несложно. А вот аутентификация
потребует дополнительных усилий.
Так же можно сделать отдельный server{}, в котором использовать ту же
зону, с теми же location'ами и задать там любые правила доступа.
On 01.08.2018 16:48, Yury Lyakh wrote:
Звучит как-то необычно, есть пример рабочего конфига? хотя бы этого
самого специального локейшна?…
что-то не придумывается конфиг который позволит внутри nginx
принудительно обновить элемент в кеше
On 31 Jul 2018, at 13:54, Igor A. Ippolitov <iippoli...@nginx.com
<mailto:iippoli...@nginx.com>> wrote:
On 31.07.2018 00:24,j...@jdwuzhere.ru <mailto:j...@jdwuzhere.ru>wrote:
On 30 Jul 2018, at 19:59, Igor A. Ippolitov <iippoli...@nginx.com
<mailto:iippoli...@nginx.com>> wrote:
On 30.07.2018 14:29, Gena Makhomed wrote:
On 30.07.2018 14:06, Igor A. Ippolitov wrote:
Мне кажется, что proxy_cache_bypass легко позволяет замещать
контент в кэше (что и делает purge, в широком смысле).
Замещать существующий контент или добавлять новый - да.
Но удалять не позволяет, в этом и состоит (небольшое) отличие.
Но ведь какой-то ответ на запрос "пурженного" контента всё равно
придёт клиенту? Почему бы не закэшить сразу его.
Или условную болванку с max-age:0, которая будет обновлена по
первому же запросу от клиента
Погодите, я что-то потерялся. Есть профиль игрока, который не
меняется неделями. Nginx всю неделю (TTL кэша) радостно отдаёт
страницу профиля из этого кэша. Но однажды, игрок начинает играть в
новое и профиль необходимо обновить. Как без purge сообщить nginx,
что информация обновилась и надо сходить в backend за новой
страницей, чтобы положить её в кэш до следующего прихода?
Как бы вы делали PURGE для профиля игрока? URL профиля вы знаете.
Для PURGE вы бы "дёрнули" запрос, который удалит ненужный элемент и в
следующий раз nginx перезапросит контент с апстрима.
Этот запрос, обычно, приходит в отдельный location с нужными
настройками: ключ кэша, права доступа, всякое такое.
В моём подходе вы "дёргаете" такой же запрос в специальный location,
который ходит в апстрим мимо кэша (proxy_cache_bypass).
В разных вариациях, апстримом будет:
либо сам nginx, который отдаёт HTTP 200 и Cache-Control: max-age=0;
либо реальный апстрим, который отдаст актуальную копию данных
В первом случае контент сразу "протухает" и его актуализируют на
первом же запросе.
Во-втором - сразу актуальный.
В следущий раз, когда запросят профиль пользователя, nginx либо
пойдёт в апстрим, либо отдаст актуальную кэшированную версию.
На первый взгляд, PURGE не кажется необходимым средством. Хотя,
вероятно. может упростить жизнь в каких-то конфигурациях.
Вот поэтому и не понятно, почему нельзя сделать директиву
proxy_cache_purge доступной в open source версии nginx?
Могу ошибаться, но коммерческую версию nginx покупают скорее всего
не из-за директивы proxy_cache_purge, а ради других возможностей.
Если не прояснится - попробовать воспроизвести как минимум без
"--add-module=../ngx_cache_purge-2.3" (не понимаю, как люди
отваживаются использовать эту поделку, она при любых внутренних
изменениях в nginx'е разносит всё же)
Если не использовать этот кривой сторонний модуль ngx_cache_purge,
то какие у пользователей open source версии nginx есть альтернативы?
Директиву proxy_cache_purge
можете сделать доступной в open source версии nginx?
P.S.
Please do not top-post.
Answer: Because it turns the discussion up-side-down.
Question: Why should I not top-post?
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
