proxy_cache_purge

[Igor A. Ippolitov]

Юрий,

Если нужно заместить элемент, то даже отдельный 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 <iippolitov на nginx.com 
>> <mailto:iippolitov на nginx.com>> wrote:
>>
>> On 31.07.2018 00:24,jd на jdwuzhere.ru <mailto:jd на jdwuzhere.ru>wrote:
>>>
>>>> On 30 Jul 2018, at 19:59, Igor A. Ippolitov <iippolitov на nginx.com 
>>>> <mailto:iippolitov на 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


----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180801/5f1d216e/attachment-0001.html>