Re: кешировать только ответы где есть определённый Set-Cookie

[Maxim Dounin]

Hello!

On Thu, Jul 07, 2022 at 02:59:34PM +0300, VovansystemS wrote:

> Добрый день,
> 
> нужно избирательно кешировать ответы бэкэнда в nginx. Некоторые ответы
> содержат Set-Cookie заголовки.По-умолчанию их кешировать не нужно, но
> если встречается определённая куки, то такой ответ нужно кешировать.
> 
> пример:
> 
> кешируем ответ с заголовком:
> Set-Cookie: pll_language=en; expires=Fri, 07-Jul-2023 11:37:39 GMT;
> Max-Age=31536000; path=/; secure; SameSite=Lax
> 
> не кешируем ответ с сессией пользователя с заголовком:
> Set-Cookie: login=i324iuhkj324; expires=Fri, 10-Jul-2023 11:37:39 GMT;
> Max-Age=31536000; path=/; secure
> 
> пытаюсь делать так:
> 
> map $upstream_http_set_cookie $bypass_cache {
>"~*.pll" 0;
> default1;
> }
> 
> server {
> [..]
> location @granted {
> [..]
> proxy_ignore_headers Set-cookie;
> proxy_no_cache $bypass_cache;
> proxy_cache_bypass $bypass_cache;
> add_header X-Bypass $bypass_cache;
> add_header X-upstream-set-cookie "aaa $upstream_http_set_cookie";
> [..]
> }
> [..]
> }
> 
> в ответе получаю:
> X-Bypass: 1
> X-upstream-set-cookie: aaa pll_language=en; expires=Fri, 07-Jul-2023
> 11:37:39 GMT; Max-Age=31536000; path=/; secure; SameSite=Lax
> 
> такое впечатление, что директива add_header корректно видит содержимое
> заголовка ответа апстрима, а вот map (и if тоже пытался) - не видят
> содержимого ни $upstream_http_set_cookie ни
> $upstream_cookie_pll_language.
> 
> Может быть есть какие-то мысли как такое лучше реализовать и возможно
> ли это вообще?

У вас map выполняется в proxy_cache_bypass, то есть до отправки 
запроса на бэкенд, и запоминает результат (некорректный, так как 
он основан на ещё не полученных от бэкенда заголовках ответа).

Очевидное решение - директиву proxy_cache_bypass убрать, она тут 
работать не может.  Решение "сохранять ли в кэш полученный от 
бэкенда ответ" принимается с помощью директивы proxy_no_cache, её 
одной вполне достаточно.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: 400 Bad Request The plain HTTP request was sent to HTTPS port

[Maxim Dounin]

Hello!

On Thu, Jul 07, 2022 at 04:57:27AM -0400, milov wrote:

> http://paste.org.ru/?j76h3l  Изменил айпи, пути и домены.

Каких-либо проблем в конфиге, относящихся к обсуждаемому вопросу, 
я не вижу: директива "ssl" в конфиге не используется вообще, 
каких-либо перенаправлений, где бы мог быть указан порт (и 
соответственно могло бы вылезти несовпадение схемы и порта), опять 
же нет.

А как выглядят сообщения об ошибках в error log'е полностью?  
Интересует в первую очередь дополнительные поля, указанные после 
ошибки, в частности, server, request, host, и referrer.  Ну и если 
проблема воспроизводится из браузера (а тема как бы намекает, что 
да) - посмотрите, какие именно запросы делаются, и что именно на 
них отвечают.

Возможно, причина где-то в php-коде, и в некорректных 
перенаправлениях, возвращаемых из него.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

кешировать только ответы где есть определённый Set-Cookie

[VovansystemS]

Добрый день,

нужно избирательно кешировать ответы бэкэнда в nginx. Некоторые ответы
содержат Set-Cookie заголовки.По-умолчанию их кешировать не нужно, но
если встречается определённая куки, то такой ответ нужно кешировать.

пример:

кешируем ответ с заголовком:
Set-Cookie: pll_language=en; expires=Fri, 07-Jul-2023 11:37:39 GMT;
Max-Age=31536000; path=/; secure; SameSite=Lax

не кешируем ответ с сессией пользователя с заголовком:
Set-Cookie: login=i324iuhkj324; expires=Fri, 10-Jul-2023 11:37:39 GMT;
Max-Age=31536000; path=/; secure

пытаюсь делать так:

map $upstream_http_set_cookie $bypass_cache {
   "~*.pll" 0;
default1;
}

server {
[..]
location @granted {
[..]
proxy_ignore_headers Set-cookie;
proxy_no_cache $bypass_cache;
proxy_cache_bypass $bypass_cache;
add_header X-Bypass $bypass_cache;
add_header X-upstream-set-cookie "aaa $upstream_http_set_cookie";
[..]
}
[..]
}

в ответе получаю:
X-Bypass: 1
X-upstream-set-cookie: aaa pll_language=en; expires=Fri, 07-Jul-2023
11:37:39 GMT; Max-Age=31536000; path=/; secure; SameSite=Lax

такое впечатление, что директива add_header корректно видит содержимое
заголовка ответа апстрима, а вот map (и if тоже пытался) - не видят
содержимого ни $upstream_http_set_cookie ни
$upstream_cookie_pll_language.

Может быть есть какие-то мысли как такое лучше реализовать и возможно
ли это вообще?

nginx -v
nginx version: nginx/1.19.2

nginx -V
nginx version: nginx/1.19.2
built by gcc 8.3.0 (Debian 8.3.0-6)
built with OpenSSL 1.1.1d  10 Sep 2019
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
--modules-path=/usr/lib/nginx/modules
--conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log
--pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock
--http-client-body-temp-path=/var/cache/nginx/client_temp
--http-proxy-temp-path=/var/cache/nginx/proxy_temp
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
--http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx
--group=nginx --with-compat --with-file-aio --with-threads
--with-http_addition_module --with-http_auth_request_module
--with-http_dav_module --with-http_flv_module
--with-http_gunzip_module --with-http_gzip_static_module
--with-http_mp4_module --with-http_random_index_module
--with-http_realip_module --with-http_secure_link_module
--with-http_slice_module --with-http_ssl_module
--with-http_stub_status_module --with-http_sub_module
--with-http_v2_module --with-mail --with-mail_ssl_module --with-stream
--with-stream_realip_module --with-stream_ssl_module
--with-stream_ssl_preread_module --with-cc-opt='-g -O2
-fdebug-prefix-map=/data/builder/debuild/nginx-1.19.2/debian/debuild-base/nginx-1.19.2=.
-fstack-protector-strong -Wformat -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now
-Wl,--as-needed -pie'
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: certbot

[Илья Шипицин]

чт, 7 июл. 2022 г. в 15:15, Evgeniy Berdnikov :

> On Thu, Jul 07, 2022 at 02:40:21PM +0500, Илья Шипицин wrote:
> >например, мы партизанским способом узнали, что можно из
> >.well-known/acme-challenge редиректить по 301, и таким образом,
> >сильно централизовать и упростить внедрение lets encrypt
>
>  Зачем редиректить? Можно же проксировать .well-known/acme-challenge.
>

в сети датацетров обычно доступ между сетевыми сегментами ограничен. и
запроксировать из кучи разных мест в единственную виртуалку с certbot - ну
так себе развлечение.

вот, например Certera 



>  Всё равно такой локейшн в конфиг нужно вставлять. И проксировать ведь
>  безопасней, потому что при проксировании узел с certbot-ом може сделать
>  вообще недоступным для соединений из интернета. А доступ к сайтам для
>  передачи сертификатов дать лишь узлу с certbot-ом.
> --
>  Eugene Berdnikov
> ___
> nginx-ru mailing list -- nginx-ru@nginx.org
> To unsubscribe send an email to nginx-ru-le...@nginx.org
>
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Перечитка конфигураций nginx

[Илья Шипицин]

а у вас в конфигах много днс имен ?

у нас основное время на "nginx -t" складывалось из днс запросов.
кеш днс (systemd-resolved  nscd  dnsmasq ...) включен ?

еще SSL серты могут много занимать на первоначальном парсинге

чт, 7 июл. 2022 г. в 13:52, ru4ag :

> Здравствуйте.
>
> Испольузем на больших серверах панель ISPmanager, в качестве веб-сервов
> связка nginx+apache(в некоторых случая nginx+php-fpm), столкнулись с такой
> ситуация что  выполнение команды nginx -t может происходить более чем 5-8
> секунд, что напрямую влияет на работу панели и т.д., в ходе анализа
> выявленно что для каждого домена панель создает несколько include, и один
> из
> них "подключает" 7-8 стандартных файлов с директории
> /etc/nginx/vhosts-includes/ и выходит что при каждом nginx -t проверяеться
> конфигурация домена, и каждого из его includ'ов, и в результате из общего
> количества открытия файлов во время nginx -t(используя просмотр через
> strace) в ~60тис файлов, 30тис обращений являються обращениями к одним и
> тем
> же 8 файлам. То есть по 3,5тис обращений на одини тот же файл.
>
> Вот и возникакет вопрос, ести ли какой то функционал возможно-го кеша, что
> бы подключенные через include одни и те же файлы не проверялись при
> 2,3,4...проверке(т.к. достаточно 1 раз проверить), и если нет(что скорее
> всего), стоит ли ожидать какой-то такой реализации в ядре nginx(как по мне
> "загнать" файл в кеш, и при последующей его проверка во время выполнения
> nginx -t/reload/restart уже не проверять)?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,294669,294669#msg-294669
>
> ___
> nginx-ru mailing list -- nginx-ru@nginx.org
> To unsubscribe send an email to nginx-ru-le...@nginx.org
>
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: certbot

[Evgeniy Berdnikov]

On Thu, Jul 07, 2022 at 02:40:21PM +0500, Илья Шипицин wrote:
>например, мы партизанским способом узнали, что можно из
>.well-known/acme-challenge редиректить по 301, и таким образом,
>сильно централизовать и упростить внедрение lets encrypt

 Зачем редиректить? Можно же проксировать .well-known/acme-challenge.
 Всё равно такой локейшн в конфиг нужно вставлять. И проксировать ведь
 безопасней, потому что при проксировании узел с certbot-ом може сделать
 вообще недоступным для соединений из интернета. А доступ к сайтам для
 передачи сертификатов дать лишь узлу с certbot-ом.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Перечитка конфигураций nginx

[Evgeniy Berdnikov]

On Thu, Jul 07, 2022 at 05:38:57AM -0400, ru4ag wrote:
> увы, такая логика панели по построению конфигураций, мы рассматриваем еще
> вариант свести все ти 8 файлов из инклуда в один файл, тогда вместо 30тис
> перечитываний, будет 3,5 тис. перечитывания конкретно него. Но не уверены
> что какое-то обновление панели это все не сломает, да и все-равно остаеться
> момент что один и тот жефайл перечитыветься 3 тис раз.

 Логика панели тут побоку. Панель раскладывает конфигурацию в набор файлов.
 Вам нужно этот набор превратить в один файл. Для этого делаете свой парсер
 директив "include", возможно, применяя для этого штатные средства других
 препроцессоров, чтобы include объявить макросом.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: certbot

[Илья Шипицин]

чт, 7 июл. 2022 г. в 14:18, Evgeniy Berdnikov :

> On Thu, Jul 07, 2022 at 01:19:01AM +0300, Maxim Dounin wrote:
> > Документация на сайте предлагает "certbot --apache" в качестве
> > основного варианта использования (например, тут:
> > https://certbot.eff.org/instructions?ws=apache=ubuntufocal), и
> > дальше уже не важно, какие ещё варианты есть: заметный процент
> > пользователей будет делать именно то, что сказали.  И получать
> > предсказуемый (точнее, непредсказуемый) результат.
>
>  Вставлю свои 2 копейки. Certbot пытается хоть как-то помочь чайникам.
>  А для чайника, как для маленького ребёнка, весь мир -- бесконечное
>  нагромождение проблем. Чайнику в паре строк конфига разобраться трудно,
>  спасти предыдущую конфигурацию он не додумается, работу http-сервера
>  он представляет себе смутно, а уж PKI и X509 это вообще ужас...
>  Смешная вроде задача "выставить в интернет свою страничку так, чтобы
>  гугл и яндекс не опустили сходу в рейтинге" становится неподъёмной.
>
>  Certbot предлагает решение, работающее для дефолтных конфигураций
>  наиболее популярных дистрибутивов. Понятно, что это решение для чайников,
>  но писать явно об этом нельзя, чтобы не травмировать психику детей. :)
>  Главное, это не единственный вариант у certbot'a.
>
> > И нет, наличие проблемы "авторы считают возможным менять конфиги"
> > в одном из вариантов использования - не означает, что в других
> > вариантах использования проблем нет.  Наличие такой проблемы
> > означает, что авторы не понимают проблему,
>
>  Может быть, понимают... Но одно дело написать код, а другое -- написать
>  адекватную документацию к нему, которая будет одинково удобна и полезна
>  как для новичка, так и для эксперта.
>
>  Certbot в вариантах, не предполагающих правки конфигов, вполне себе
>  работает. Можно сказать, "поставил и забыл".
>
>  Думаю, для командны Nginx было бы неплохо вставить в дистрибутивный
>  конфиг некую заготовку для "location /.well-known/acme-challenge {..}",
>

с документированием механизмов интеграции ACME с веб-серверами вообще не
хватает качественной документации.

например, мы партизанским способом узнали, что можно из
.well-known/acme-challenge редиректить по 301, и таким образом,
сильно централизовать и упростить внедрение lets encrypt


>  и написать там комментарии как ею пользоваться. Возможно, пообщаться
>  ещё с писателями certbot'a, чтобы вместе с ними сделать использование
>  этой заготовки удобным и безопасным. Тогда всем новичкам станет легче.
> --
>  Eugene Berdnikov
> ___
> nginx-ru mailing list -- nginx-ru@nginx.org
> To unsubscribe send an email to nginx-ru-le...@nginx.org
>
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Перечитка конфигураций nginx

[ru4ag]

увы, такая логика панели по построению конфигураций, мы рассматриваем еще
вариант свести все ти 8 файлов из инклуда в один файл, тогда вместо 30тис
перечитываний, будет 3,5 тис. перечитывания конкретно него. Но не уверены
что какое-то обновление панели это все не сломает, да и все-равно остаеться
момент что один и тот жефайл перечитыветься 3 тис раз.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,294669,294675#msg-294675

___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Перечитка конфигураций nginx

[Evgeniy Berdnikov]

On Thu, Jul 07, 2022 at 05:16:38AM -0400, ru4ag wrote:
> и проблема не в числе инклюдов, а в том что перечитываеться один и тот же
> файл(что идет в инклюде каждого хоста) множество раз, хотя логично было бы
> его перечитать 1 раз.

 Интерпретация инклуда зависит от того, в какой блок он считывается...

 Если хочется сэкономить на на сисколах open() и close(), то что мешает
 генерить общий конфиг (через m4, cpp, etc), и затем загружать его целиком?
-- 
 Eugene Berdnikov
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: certbot

[Evgeniy Berdnikov]

On Thu, Jul 07, 2022 at 01:19:01AM +0300, Maxim Dounin wrote:
> Документация на сайте предлагает "certbot --apache" в качестве 
> основного варианта использования (например, тут: 
> https://certbot.eff.org/instructions?ws=apache=ubuntufocal), и 
> дальше уже не важно, какие ещё варианты есть: заметный процент 
> пользователей будет делать именно то, что сказали.  И получать 
> предсказуемый (точнее, непредсказуемый) результат.

 Вставлю свои 2 копейки. Certbot пытается хоть как-то помочь чайникам.
 А для чайника, как для маленького ребёнка, весь мир -- бесконечное
 нагромождение проблем. Чайнику в паре строк конфига разобраться трудно,
 спасти предыдущую конфигурацию он не додумается, работу http-сервера
 он представляет себе смутно, а уж PKI и X509 это вообще ужас...
 Смешная вроде задача "выставить в интернет свою страничку так, чтобы
 гугл и яндекс не опустили сходу в рейтинге" становится неподъёмной.

 Certbot предлагает решение, работающее для дефолтных конфигураций
 наиболее популярных дистрибутивов. Понятно, что это решение для чайников,
 но писать явно об этом нельзя, чтобы не травмировать психику детей. :)
 Главное, это не единственный вариант у certbot'a.
 
> И нет, наличие проблемы "авторы считают возможным менять конфиги" 
> в одном из вариантов использования - не означает, что в других 
> вариантах использования проблем нет.  Наличие такой проблемы 
> означает, что авторы не понимают проблему,

 Может быть, понимают... Но одно дело написать код, а другое -- написать
 адекватную документацию к нему, которая будет одинково удобна и полезна
 как для новичка, так и для эксперта.

 Certbot в вариантах, не предполагающих правки конфигов, вполне себе
 работает. Можно сказать, "поставил и забыл".

 Думаю, для командны Nginx было бы неплохо вставить в дистрибутивный
 конфиг некую заготовку для "location /.well-known/acme-challenge {..}",
 и написать там комментарии как ею пользоваться. Возможно, пообщаться
 ещё с писателями certbot'a, чтобы вместе с ними сделать использование
 этой заготовки удобным и безопасным. Тогда всем новичкам станет легче.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Перечитка конфигураций nginx

[ru4ag]

отключение данной директории(просто переименовав в
/etc/nginx/vhosts-includes_) снижало время на перечитывание до 1.8-2сек, что
в 2-3 раза быстрее.

и проблема не в числе инклюдов, а в том что перечитываеться один и тот же
файл(что идет в инклюде каждого хоста) множество раз, хотя логично было бы
его перечитать 1 раз.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,294669,294672#msg-294672

___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: 400 Bad Request The plain HTTP request was sent to HTTPS port

[milov]

http://paste.org.ru/?j76h3l  Изменил айпи, пути и домены.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,294635,294670#msg-294670

___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: Перечитка конфигураций nginx

[Anton Kiryushkin]

5-7 секунд еще не долго. Вот минут 5 - это было больно. И насколько я
помню, влияет не число инклудов, а число локейшенов и апстримов.

On Thu, 7 Jul 2022 at 09:54, ru4ag  wrote:

> Здравствуйте.
>
> Испольузем на больших серверах панель ISPmanager, в качестве веб-сервов
> связка nginx+apache(в некоторых случая nginx+php-fpm), столкнулись с такой
> ситуация что  выполнение команды nginx -t может происходить более чем 5-8
> секунд, что напрямую влияет на работу панели и т.д., в ходе анализа
> выявленно что для каждого домена панель создает несколько include, и один
> из
> них "подключает" 7-8 стандартных файлов с директории
> /etc/nginx/vhosts-includes/ и выходит что при каждом nginx -t проверяеться
> конфигурация домена, и каждого из его includ'ов, и в результате из общего
> количества открытия файлов во время nginx -t(используя просмотр через
> strace) в ~60тис файлов, 30тис обращений являються обращениями к одним и
> тем
> же 8 файлам. То есть по 3,5тис обращений на одини тот же файл.
>
> Вот и возникакет вопрос, ести ли какой то функционал возможно-го кеша, что
> бы подключенные через include одни и те же файлы не проверялись при
> 2,3,4...проверке(т.к. достаточно 1 раз проверить), и если нет(что скорее
> всего), стоит ли ожидать какой-то такой реализации в ядре nginx(как по мне
> "загнать" файл в кеш, и при последующей его проверка во время выполнения
> nginx -t/reload/restart уже не проверять)?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,294669,294669#msg-294669
>
> ___
> nginx-ru mailing list -- nginx-ru@nginx.org
> To unsubscribe send an email to nginx-ru-le...@nginx.org
>


-- 
Best regards,
Anton Kiryushkin
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Перечитка конфигураций nginx

[ru4ag]

Здравствуйте.

Испольузем на больших серверах панель ISPmanager, в качестве веб-сервов
связка nginx+apache(в некоторых случая nginx+php-fpm), столкнулись с такой
ситуация что  выполнение команды nginx -t может происходить более чем 5-8
секунд, что напрямую влияет на работу панели и т.д., в ходе анализа
выявленно что для каждого домена панель создает несколько include, и один из
них "подключает" 7-8 стандартных файлов с директории
/etc/nginx/vhosts-includes/ и выходит что при каждом nginx -t проверяеться 
конфигурация домена, и каждого из его includ'ов, и в результате из общего
количества открытия файлов во время nginx -t(используя просмотр через
strace) в ~60тис файлов, 30тис обращений являються обращениями к одним и тем
же 8 файлам. То есть по 3,5тис обращений на одини тот же файл.

Вот и возникакет вопрос, ести ли какой то функционал возможно-го кеша, что
бы подключенные через include одни и те же файлы не проверялись при
2,3,4...проверке(т.к. достаточно 1 раз проверить), и если нет(что скорее
всего), стоит ли ожидать какой-то такой реализации в ядре nginx(как по мне
"загнать" файл в кеш, и при последующей его проверка во время выполнения
nginx -t/reload/restart уже не проверять)?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,294669,294669#msg-294669

___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: 400 Bad Request The plain HTTP request was sent to HTTPS port

[Антон Горлов via nginx-ru]

07.07.2022 11:34, milov пишет:

А как тут прикрепить файл? полотно длинное сюда постить.


Нет сюда простыню не надо.
Запостите содержимое например на http://paste.org.ru/ ,а сюда ссылку
___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org

Re: 400 Bad Request The plain HTTP request was sent to HTTPS port

[milov]

А как тут прикрепить файл? полотно длинное сюда постить.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,294635,294667#msg-294667

___
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-le...@nginx.org