From yorick на ya.ru  Wed Aug  1 13:48:12 2018
From: yorick на ya.ru (Yury Lyakh)
Date: Wed, 1 Aug 2018 15:48:12 +0200
Subject: proxy_cache_purge
In-Reply-To: <b93ec27f-e2c5-6bfe-9895-2fe196b02019@nginx.com>
References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru>
 <20180717122900.GZ56558@mdounin.ru>
 <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru>
 <20180726124004.GP56558@mdounin.ru>
 <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com>
 <b71d2b30-5c56-4e05-d959-11fb56e0afa6@nginx.com>
 <3306afa5-2a2b-b49a-2f5e-da144eab31f1@csdoc.com>
 <b9b95169-8ec9-899b-38cb-1f1345cc764f@nginx.com>
 <16BAE8F8-292D-49AD-9E6D-0AF2113BF7A0@jdwuzhere.ru>
 <b93ec27f-e2c5-6bfe-9895-2fe196b02019@nginx.com>
Message-ID: <99393615-020E-4490-97EA-BA27D0770EDF@ya.ru>

Звучит как-то необычно, есть пример рабочего конфига? хотя бы этого самого специального локейшна?…
что-то не придумывается конфиг который позволит внутри nginx принудительно обновить элемент в кеше

> On 31 Jul 2018, at 13:54, Igor A. Ippolitov <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> 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
>>> 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 <mailto:nginx-ru на nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180801/0dc7b3b1/attachment-0001.html>

From iippolitov на nginx.com  Wed Aug  1 15:28:45 2018
From: iippolitov на nginx.com (Igor A. Ippolitov)
Date: Wed, 1 Aug 2018 18:28:45 +0300
Subject: proxy_cache_purge
In-Reply-To: <99393615-020E-4490-97EA-BA27D0770EDF@ya.ru>
References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru>
 <20180717122900.GZ56558@mdounin.ru>
 <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru>
 <20180726124004.GP56558@mdounin.ru>
 <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com>
 <b71d2b30-5c56-4e05-d959-11fb56e0afa6@nginx.com>
 <3306afa5-2a2b-b49a-2f5e-da144eab31f1@csdoc.com>
 <b9b95169-8ec9-899b-38cb-1f1345cc764f@nginx.com>
 <16BAE8F8-292D-49AD-9E6D-0AF2113BF7A0@jdwuzhere.ru>
 <b93ec27f-e2c5-6bfe-9895-2fe196b02019@nginx.com>
 <99393615-020E-4490-97EA-BA27D0770EDF@ya.ru>
Message-ID: <4436e136-3c37-5593-5188-4009e0bf89cc@nginx.com>

Юрий,

Если нужно заместить элемент, то даже отдельный 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 было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180801/5f1d216e/attachment-0001.html>

From nginx-forum на forum.nginx.org  Sat Aug  4 11:48:47 2018
From: nginx-forum на forum.nginx.org (Romano)
Date: Sat, 04 Aug 2018 07:48:47 -0400
Subject: =?UTF-8?B?UmU6INCc0LXRhdCw0L3QuNC30Lwg0L3QsNC30L3QsNGH0LXQvdC40Y8g0L/QtdGA?=
 =?UTF-8?B?0LXQvNC10L3QvdC+0LkgJHNzbCBzZXNzaW9uIGlk?=
In-Reply-To: <72AD54D2-4F33-4103-8EA3-F00214EB5FB7@kopeyko.ru>
References: <72AD54D2-4F33-4103-8EA3-F00214EB5FB7@kopeyko.ru>
Message-ID: <11e4bb2d67e99072ca063c23f1ab49f3.NginxMailingListRussian@forum.nginx.org>

И как же они это делают? Пробую соединения через консоль openssl, $ssl
session id не регистрируется, хотя получаю дешифрованный контент сайта. Этот
идентификатор может быть передан через HTTP заголовки?

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


From mdounin на mdounin.ru  Mon Aug  6 13:08:16 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 6 Aug 2018 16:08:16 +0300
Subject: =?UTF-8?B?UmU6INCc0LXRhdCw0L3QuNC30Lwg0L3QsNC30L3QsNGH0LXQvdC40Y8g0L/QtdGA?=
 =?UTF-8?B?0LXQvNC10L3QvdC+0LkgJHNzbCBzZXNzaW9uIGlk?=
In-Reply-To: <11e4bb2d67e99072ca063c23f1ab49f3.NginxMailingListRussian@forum.nginx.org>
References: <72AD54D2-4F33-4103-8EA3-F00214EB5FB7@kopeyko.ru>
 <11e4bb2d67e99072ca063c23f1ab49f3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180806130815.GS56558@mdounin.ru>

Hello!

On Sat, Aug 04, 2018 at 07:48:47AM -0400, Romano wrote:

> И как же они это делают? Пробую соединения через консоль openssl, $ssl
> session id не регистрируется, хотя получаю дешифрованный контент сайта. Этот
> идентификатор может быть передан через HTTP заголовки?

Существует два варианта назначения Session ID:

- В случае использования серверного кэша сессий - session id 
  выбирается сервером, и доступен серверу с момента установления 
  первого соединения.  Соответственно доступна переменная 
  $ssl_session_id в клиенте.

- В случае использова TLS session tickets - session id выбирается 
  клиентом при использовании тикета.  Соответственно переменная 
  $ssl_session_id доступна только при повторном использовании 
  сессии.  Может, впрочем, и не быть доступна вовсе - если клиент 
  предпочтёт session id не выбирать (но такие клиенты, AFAIK, 
  редкость).  Подробности обо всём этом можно прочитать в 
  https://tools.ietf.org/html/rfc5077#section-3.4.

Кроме того, если не используется ни кэш сессий, ни тикеты - 
session id вообще не будет выбираться, и соответственно переменная 
будет пустой.

-- 
Maxim Dounin
http://mdounin.ru/

From schors на gmail.com  Mon Aug  6 21:48:59 2018
From: schors на gmail.com (Phil Kulin)
Date: Tue, 7 Aug 2018 00:48:59 +0300
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LjQvdGP0YLRjCDQv9GA0L7QutGB0LjRgNC+0LLQsNC9?=
 =?UTF-8?B?0L3Ri9C5IGh0dHBzINGBINC90LXRgdC60L7Qu9GM0LrQuNGFINC40YHRgtC+?=
 =?UTF-8?B?0YfQvdC40LrQvtCyLCDQsiDRgtC+0Lwg0YfQuNGB0LvQtSDRgSBDbG91ZEZs?=
 =?UTF-8?B?YXJlID8=?=
In-Reply-To: <1522620354.361900096.krzplbj9@frv37.fwdcdn.com>
References: <1522620354.361900096.krzplbj9@frv37.fwdcdn.com>
Message-ID: <CAK=u2EXYxbX_gPC09wULHzhyZTQS24XotczVxTrK9FooQK5XAg@mail.gmail.com>

Ничего не придумали?

2018-04-02 1:11 GMT+03:00 Vladislav Prodan <universite на ukr.net>:
>
> Здравствуйте.
>
> Subj.
> nginx/1.12.1
>
> На основном сервере соорудил такой конфиг:
>
> server {
>         server_name .domain.com ;
>         ...
>         listen 443 ssl;
>         listen 444 ssl proxy_protocol;
>         ...
>         # Real IP from CloudFlare
>         include /etc/nginx/cloudflare.conf;
>         real_ip_header CF-Connecting-IP;
>         ...
>         set_real_ip_from 1.1.1.1/32;
>         real_ip_header proxy_protocol;
>         ...
>
> }
>
> Проблема в том, что у CloudFlare одно значение real_ip_header, а для обычной tcp прокси (haproxy) - другое значение.
>
> Попытался такой вставить блок,
> if ($remote_addr = 1.1.1.1) {
>      set_real_ip_from 1.1.1.1/32;
>      real_ip_header proxy_protocol;
> }
> Но тут можно использовать только редиректы и real_ip_header нельзя переназначить...
>
> Подскажите решение.
>
> --
>  Vladislav V. Prodan
>  System & Network Administrator
>  support.od.ua
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



-- 
Non nobis Domine non nobis sed Nomini Tuo da gloriam
Phil Kulin

From oleg на mamontov.net  Mon Aug  6 22:07:06 2018
From: oleg на mamontov.net (Oleg A. Mamontov)
Date: Tue, 7 Aug 2018 01:07:06 +0300
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LjQvdGP0YLRjCDQv9GA0L7QutGB0LjRgNC+0LLQsNC9?=
 =?UTF-8?B?0L3Ri9C5IGh0dHBzINGBINC90LXRgdC60L7Qu9GM0LrQuNGFINC40YHRgtC+?=
 =?UTF-8?B?0YfQvdC40LrQvtCyLCDQsiDRgtC+0Lwg0YfQuNGB0LvQtSDRgSBDbG91ZEZs?=
 =?UTF-8?B?YXJlID8=?=
In-Reply-To: <CAK=u2EXYxbX_gPC09wULHzhyZTQS24XotczVxTrK9FooQK5XAg@mail.gmail.com>
References: <1522620354.361900096.krzplbj9@frv37.fwdcdn.com>
 <CAK=u2EXYxbX_gPC09wULHzhyZTQS24XotczVxTrK9FooQK5XAg@mail.gmail.com>
Message-ID: <20180806220706.jj6y6ys2h4fipubx@xenon.mamontov.net>

On Tue, Aug 07, 2018 at 12:48:59AM +0300, Phil Kulin wrote:
>Ничего не придумали?

Кажется напрашивается самое простое решение: сделать два server-блока и
продублировать общую содержательную часть с помощью include:

server {
    server_name .domain.com;

    listen 443 ssl;
    real_ip_header CF-Connecting-IP;
    set_real_ip_from 1.2.3.4;

    include /etc/nginx/common_part.conf;
}
server {
    server_name .domain.com;

    listen 444 ssl proxy_protocol;
    real_ip_header proxy_protocol;
    set_real_ip_from 2.3.4.5;

    include /etc/nginx/common_part.conf;
}


-- 
Cheers,
Oleg A. Mamontov

mailto: oleg на mamontov.net

skype:  lonerr11
cell:   +7 (903) 798-1352

From nginx-forum на forum.nginx.org  Tue Aug  7 09:58:03 2018
From: nginx-forum на forum.nginx.org (Romano)
Date: Tue, 07 Aug 2018 05:58:03 -0400
Subject: =?UTF-8?B?UmU6INCc0LXRhdCw0L3QuNC30Lwg0L3QsNC30L3QsNGH0LXQvdC40Y8g0L/QtdGA?=
 =?UTF-8?B?0LXQvNC10L3QvdC+0LkgJHNzbCBzZXNzaW9uIGlk?=
In-Reply-To: <20180806130815.GS56558@mdounin.ru>
References: <20180806130815.GS56558@mdounin.ru>
Message-ID: <cee7772b5737326c65745c20dd05f90f.NginxMailingListRussian@forum.nginx.org>

Спасибо!

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


From nginx на mva.name  Wed Aug  8 08:15:02 2018
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Wed, 08 Aug 2018 11:15:02 +0300
Subject: =?UTF-8?B?VW5pdDog0LrQvtC80LzQuNGCLCDQu9C+0LzQsNGO0YnQuNC5INGB0LHQvtGA0Lo=?=
 =?UTF-8?B?0YM=?=
Message-ID: <2377859.G7dJiVO7E6@tp>

Здравствуйте!
Тут позавчера вечером прилетел вот такой вот коммит:
http://hg.nginx.org/unit/diff/e0f0cd7d244a/src/perl/nxt_perl_psgi.c
(ссылка на конкретный файл, чтобы понять о чём речь)

Теперь в нём (файле) есть такая вот строка:

> PerlInterpreter  *my_perl;

Точнее, таких вхождений там теперь несколько, но нас интересует та, что на 
данный момент на 804 строке.

Потому что она (кроме своей установки) нигде не используется.
При этом в билдсистеме используется замечательный флаг

> -Werror


И вот всё это вместе приводит к:

> make -j5 -s -l2 all
> src/perl/nxt_perl_psgi.c: In function ‘nxt_perl_psgi_io_read’:
> src/perl/nxt_perl_psgi.c:804:30: error: variable ‘my_perl’ set but not used 
[-Werror=unused-but-set-variable]
>      PerlInterpreter         *my_perl;
>                              ^~~~~~~
> cc1: all warnings being treated as errors
> make: *** [build/Makefile:1502: build/src/perl/nxt_perl_psgi-perl.o] Error 1


Почините, пожалуйста :)

From alexander.borisov на nginx.com  Wed Aug  8 12:13:24 2018
From: alexander.borisov на nginx.com (Alexander Borisov)
Date: Wed, 8 Aug 2018 15:13:24 +0300
Subject: =?UTF-8?B?UmU6IFVuaXQ6INC60L7QvNC80LjRgiwg0LvQvtC80LDRjtGJ0LjQuSDRgdCx0L4=?=
 =?UTF-8?B?0YDQutGD?=
In-Reply-To: <2377859.G7dJiVO7E6@tp>
References: <2377859.G7dJiVO7E6@tp>
Message-ID: <8D5B01D9-8CC0-4F55-9974-941C7DF9F069@nginx.com>

Приветствую!

Починили в коммите: http://hg.nginx.org/unit/rev/9290ae53e8bf <http://hg.nginx.org/unit/rev/9290ae53e8bf>

Спасибо за сообщение!


> 8 авг. 2018 г., в 11:15, Vadim A. Misbakh-Soloviov <nginx на mva.name> написал(а):
> 
> Здравствуйте!
> Тут позавчера вечером прилетел вот такой вот коммит:
> http://hg.nginx.org/unit/diff/e0f0cd7d244a/src/perl/nxt_perl_psgi.c
> (ссылка на конкретный файл, чтобы понять о чём речь)
> 
> Теперь в нём (файле) есть такая вот строка:
> 
>> PerlInterpreter  *my_perl;
> 
> Точнее, таких вхождений там теперь несколько, но нас интересует та, что на 
> данный момент на 804 строке.
> 
> Потому что она (кроме своей установки) нигде не используется.
> При этом в билдсистеме используется замечательный флаг
> 
>> -Werror
> 
> 
> И вот всё это вместе приводит к:
> 
>> make -j5 -s -l2 all
>> src/perl/nxt_perl_psgi.c: In function ‘nxt_perl_psgi_io_read’:
>> src/perl/nxt_perl_psgi.c:804:30: error: variable ‘my_perl’ set but not used 
> [-Werror=unused-but-set-variable]
>>     PerlInterpreter         *my_perl;
>>                             ^~~~~~~
>> cc1: all warnings being treated as errors
>> make: *** [build/Makefile:1502: build/src/perl/nxt_perl_psgi-perl.o] Error 1
> 
> 
> Почините, пожалуйста :)
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

From nginx на kinetiksoft.com  Wed Aug  8 19:53:41 2018
From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=)
Date: Wed, 8 Aug 2018 22:53:41 +0300
Subject: =?UTF-8?B?dW5pdDog0LzQtdGF0LDQvdC40LfQvCDQvtC/0YDQtdC00LXQu9C10L3QuNGPINCw?=
 =?UTF-8?B?0LTRgNC10YHQsCDQutC70LjQtdC90YLQsCDRgtC40L/QsCByZWFsaXAg0Lgg?=
 =?UTF-8?B?0L/QtdGA0LXQtNCw0YfQsCDQt9Cw0LPQvtC70L7QstC60L7Qsg==?=
Message-ID: <a94b98e1-5110-82b3-bf0c-27bdc773b400@kinetiksoft.com>

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

Правильно ли я понимаю, что сейчас unit не умеет передавать в
$_SERVER['REMOTE_ADDR']   ip клиента, а не проксирующего nginx?
Переделывать весь наш код, чтоб брал IP из другого заголовка будет жестко.

Планируется ли это исправить? Когда примерно? Сейчас это единственный
для меня блокирующий недостаток для внедрения unit массово в продакшен.

Так же интересно, когда планируется ввести возможность передавать вы
пыху любые заголовки массива $_SERVER, а не только HTTP_*. Это
собственно является решением и предыдущего вопроса.


С уважением, Иван.


From vbart на nginx.com  Thu Aug  9 07:37:23 2018
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 09 Aug 2018 10:37:23 +0300
Subject: =?UTF-8?B?UmU6IHVuaXQ6INC80LXRhdCw0L3QuNC30Lwg0L7Qv9GA0LXQtNC10LvQtdC90Lg=?=
 =?UTF-8?B?0Y8g0LDQtNGA0LXRgdCwINC60LvQuNC10L3RgtCwINGC0LjQv9CwIHJlYWxp?=
 =?UTF-8?B?cCDQuCDQv9C10YDQtdC00LDRh9CwINC30LDQs9C+0LvQvtCy0LrQvtCy?=
In-Reply-To: <a94b98e1-5110-82b3-bf0c-27bdc773b400@kinetiksoft.com>
References: <a94b98e1-5110-82b3-bf0c-27bdc773b400@kinetiksoft.com>
Message-ID: <2168474.s7RRUIZoAF@vbart-laptop>

On Wednesday, 8 August 2018 22:53:41 MSK Иван wrote:
> Здравствуйте!
> 
> Правильно ли я понимаю, что сейчас unit не умеет передавать в
> $_SERVER['REMOTE_ADDR']   ip клиента, а не проксирующего nginx?
> Переделывать весь наш код, чтоб брал IP из другого заголовка будет жестко.

Да, туда в настоящий момент передается информация из сокета.

Я бы сейчас решил эту задачу маленькой прослойкой в виде небольшого php
скрипта, который заменяет содержимое $_SERVER['REMOTE_ADDR'] из HTTP_
заголовка, а далее выполняет уже основной скрипт, запрошенный.  Так не
потребуется вносить каких-либо изменений в остальной код, а прослойку
в бущуем можно будет просто убрать.


> 
> Планируется ли это исправить? Когда примерно? Сейчас это единственный
> для меня блокирующий недостаток для внедрения unit массово в продакшен.

Насколько я понимаю, некое подобие realip модуля решило бы Вашу задачу?


> 
> Так же интересно, когда планируется ввести возможность передавать вы
> пыху любые заголовки массива $_SERVER, а не только HTTP_*. Это
> собственно является решением и предыдущего вопроса.

Сейчас это не очень простая задача.  Сама по себе возможность задавать
массив $_SERVER не представляет сложности, но вряд ли будет полезно
указывать там какие-то константы.  А что-то более осмысленное требует
уже реализовывать поддержку переменных или какой-то похожий механизм.
Возможно где-то к концу года, в начале следующего мы что-то подобное
сделаем.

--
Валентин

From jd на jdwuzhere.ru  Mon Aug 13 12:25:18 2018
From: jd на jdwuzhere.ru (Vladimir Sopot)
Date: Mon, 13 Aug 2018 15:25:18 +0300
Subject: proxy_cache_purge
In-Reply-To: <4436e136-3c37-5593-5188-4009e0bf89cc@nginx.com>
References: <9CC1FDE7-5053-4E35-82B3-92271D6EFCBA@jdwuzhere.ru>
 <20180717122900.GZ56558@mdounin.ru>
 <18508885-4C3C-441F-BCAF-B49BC8A08C2E@jdwuzhere.ru>
 <20180726124004.GP56558@mdounin.ru>
 <06662ecd-b333-6c96-4c4d-40f47fa4b032@csdoc.com>
 <b71d2b30-5c56-4e05-d959-11fb56e0afa6@nginx.com>
 <3306afa5-2a2b-b49a-2f5e-da144eab31f1@csdoc.com>
 <b9b95169-8ec9-899b-38cb-1f1345cc764f@nginx.com>
 <16BAE8F8-292D-49AD-9E6D-0AF2113BF7A0@jdwuzhere.ru>
 <b93ec27f-e2c5-6bfe-9895-2fe196b02019@nginx.com>
 <99393615-020E-4490-97EA-BA27D0770EDF@ya.ru>
 <4436e136-3c37-5593-5188-4009e0bf89cc@nginx.com>
Message-ID: <A7DFB79F-3B9B-4532-8E30-D2D1F6CA6388@jdwuzhere.ru>

Как-то слишком просто..

geo $force_bypass {
	127.0.0.1 1;
	default 0;
}

Добавил в fastcgi_cache_bypass $force_bypass

на запрос с localhost отдаётся новый контент, всё круто, в логах $upstream_cache_status=BYPASS, но кэш не обновляется и на запрос снаружи отдаётся старая версия с  $upstream_cache_status=HIT. На диске в кэше лежит старый файл. 

Чего не хватает котёнку?

> On 1 Aug 2018, at 18:28, Igor A. Ippolitov <iippolitov на nginx.com> wrote:
> 
> Юрий,
> 
> Если нужно заместить элемент, то даже отдельный 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 <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 <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 <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 <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 было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180813/9a3f0d72/attachment-0001.html>

From andrey на kopeyko.ru  Mon Aug 13 21:57:24 2018
From: andrey на kopeyko.ru (Andrey Kopeyko)
Date: Tue, 14 Aug 2018 00:57:24 +0300 (MSK)
Subject: =?UTF-8?B?UmU6INCc0LXRhdCw0L3QuNC30Lwg0L3QsNC30L3QsNGH0LXQvdC40Y8g0L/QtdGA?=
 =?UTF-8?B?0LXQvNC10L3QvdC+0LkgJHNzbCBzZXNzaW9uIGlk?=
In-Reply-To: <11e4bb2d67e99072ca063c23f1ab49f3.NginxMailingListRussian@forum.nginx.org>
References: <72AD54D2-4F33-4103-8EA3-F00214EB5FB7@kopeyko.ru>
 <11e4bb2d67e99072ca063c23f1ab49f3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <alpine.DEB.2.20.1808140054060.5839@AKnb6>

On Sat, 4 Aug 2018, Romano wrote:

> И как же они это делают? Пробую соединения через консоль openssl, $ssl
> session id не регистрируется,

Ну вот же он:

kaa на AKnb6:~$ echo "" |openssl s_client -connect dev.kopeyko.ru:443 2>/dev/null 
|grep -1 Session-ID:
     Cipher    : ECDHE-RSA-AES256-SHA
     Session-ID: 18BB9A4672CFB2C19D64F156BD1ECA3E9EDDBBE558DCAF79F71CF434537770C9
     Session-ID-ctx:
kaa на AKnb6:~$


> Этот идентификатор может быть передан через HTTP заголовки?

Нет, не может. Это параметр TLS соединения, устанавливаемого _до_ начала 
работы протокола HTTP.


-- 
Best regards,
Andrey Kopeyko <andrey на kopeyko.ru>

From nginx-forum на forum.nginx.org  Wed Aug 15 05:24:07 2018
From: nginx-forum на forum.nginx.org (simonovbs)
Date: Wed, 15 Aug 2018 01:24:07 -0400
Subject: =?UTF-8?B?0J3QtdCy0L7Qt9C80L7QttC90L4g0YHQtNC10LvQsNGC0YwgcmVsb2FkINC/0YA=?=
 =?UTF-8?B?0Lgg0L3QtdC60L7RgtC+0YDRi9GFINC40LfQvNC10L3QtdC90LjRj9GFIGxp?=
 =?UTF-8?B?c3Rlbg==?=
Message-ID: <91dad92b0741dc1f29f94f62ffe4f37a.NginxMailingListRussian@forum.nginx.org>

Привет! 
Когда в конфигурация меняется listen, пример:
listen 80; -> listen 127.0.0.1:80;
reload перестает работать, при этом 
# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# systemctl reload nginx
# tail /var/log/nginx/error.log
2018/08/15 07:55:23 [emerg] 195377#0: bind() to 127.0.0.1:27183 failed (98:
Address already in use)
2018/08/15 07:55:23 [emerg] 195377#0: bind() to 127.0.0.1:27183 failed (98:
Address already in use)
2018/08/15 07:55:23 [emerg] 195377#0: bind() to 127.0.0.1:27183 failed (98:
Address already in use)
2018/08/15 07:55:23 [emerg] 195377#0: bind() to 127.0.0.1:27183 failed (98:
Address already in use)
2018/08/15 07:55:23 [emerg] 195377#0: bind() to 127.0.0.1:27183 failed (98:
Address already in use)
2018/08/15 07:55:23 [emerg] 195377#0: still could not bind()

Логичный выход из ситуации сделать restart. Печально что nginx -t не выдает
ошибок, в связи с чем вопрос: можно ли как-нибудь идентифицировать ситуацию
когда reload сломан кроме как по логам?

Воспроизвелось на nginx/1.12.2, nginx/1.13.12, CentOS Linux release 7.5.1804

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


From vbart на nginx.com  Wed Aug 15 16:23:30 2018
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 15 Aug 2018 19:23:30 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INGB0LTQtdC70LDRgtGMIHJlbG9hZCA=?=
 =?UTF-8?B?0L/RgNC4INC90LXQutC+0YLQvtGA0YvRhSDQuNC30LzQtdC90LXQvdC40Y8=?=
 =?UTF-8?B?0YUgbGlzdGVu?=
In-Reply-To: <91dad92b0741dc1f29f94f62ffe4f37a.NginxMailingListRussian@forum.nginx.org>
References: <91dad92b0741dc1f29f94f62ffe4f37a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1950543.ptVRA82Chr@vbart-workstation>

On Wednesday 15 August 2018 01:24:07 simonovbs wrote:
> Привет! 
> Когда в конфигурация меняется listen, пример:
> listen 80; -> listen 127.0.0.1:80;
> reload перестает работать, при этом 
> # nginx -t
> nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /etc/nginx/nginx.conf test is successful
> # systemctl reload nginx
> # tail /var/log/nginx/error.log
> 2018/08/15 07:55:23 [emerg] 195377#0: bind() to 127.0.0.1:27183 failed (98:
> Address already in use)
> 2018/08/15 07:55:23 [emerg] 195377#0: bind() to 127.0.0.1:27183 failed (98:
> Address already in use)
> 2018/08/15 07:55:23 [emerg] 195377#0: bind() to 127.0.0.1:27183 failed (98:
> Address already in use)
> 2018/08/15 07:55:23 [emerg] 195377#0: bind() to 127.0.0.1:27183 failed (98:
> Address already in use)
> 2018/08/15 07:55:23 [emerg] 195377#0: bind() to 127.0.0.1:27183 failed (98:
> Address already in use)
> 2018/08/15 07:55:23 [emerg] 195377#0: still could not bind()

Так работают сокеты в Linux.

См. https://trac.nginx.org/nginx/ticket/1457



> 
> Логичный выход из ситуации сделать restart. Печально что nginx -t не выдает
> ошибок, в связи с чем вопрос: можно ли как-нибудь идентифицировать ситуацию
> когда reload сломан кроме как по логам?
> 
> Воспроизвелось на nginx/1.12.2, nginx/1.13.12, CentOS Linux release 7.5.1804
> 

У сигналов обратной связи нет, поэтому необходимо всегда смотреть логи.

--
Валентин Бартенев

From chipitsine на gmail.com  Wed Aug 15 17:46:08 2018
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 15 Aug 2018 22:46:08 +0500
Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INGB0LTQtdC70LDRgtGMIHJlbG9hZCA=?=
 =?UTF-8?B?0L/RgNC4INC90LXQutC+0YLQvtGA0YvRhSDQuNC30LzQtdC90LXQvdC40Y8=?=
 =?UTF-8?B?0YUgbGlzdGVu?=
In-Reply-To: <1950543.ptVRA82Chr@vbart-workstation>
References: <91dad92b0741dc1f29f94f62ffe4f37a.NginxMailingListRussian@forum.nginx.org>
 <1950543.ptVRA82Chr@vbart-workstation>
Message-ID: <CAFHpkQH-3=8xH+ineeCR6+kamkeaP+uu=LmY5pi6rNtH6PUhQg@mail.gmail.com>

ср, 15 авг. 2018 г. в 21:23, Валентин Бартенев <vbart на nginx.com>:

> On Wednesday 15 August 2018 01:24:07 simonovbs wrote:
> > Привет!
> > Когда в конфигурация меняется listen, пример:
> > listen 80; -> listen 127.0.0.1:80;
> > reload перестает работать, при этом
> > # nginx -t
> > nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> > nginx: configuration file /etc/nginx/nginx.conf test is successful
> > # systemctl reload nginx
> > # tail /var/log/nginx/error.log
> > 2018/08/15 07:55:23 [emerg] 195377#0: bind() to 127.0.0.1:27183 failed
> (98:
> > Address already in use)
> > 2018/08/15 07:55:23 [emerg] 195377#0: bind() to 127.0.0.1:27183 failed
> (98:
> > Address already in use)
> > 2018/08/15 07:55:23 [emerg] 195377#0: bind() to 127.0.0.1:27183 failed
> (98:
> > Address already in use)
> > 2018/08/15 07:55:23 [emerg] 195377#0: bind() to 127.0.0.1:27183 failed
> (98:
> > Address already in use)
> > 2018/08/15 07:55:23 [emerg] 195377#0: bind() to 127.0.0.1:27183 failed
> (98:
> > Address already in use)
> > 2018/08/15 07:55:23 [emerg] 195377#0: still could not bind()
>
> Так работают сокеты в Linux.
>
> См. https://trac.nginx.org/nginx/ticket/1457
>
>
>
> >
> > Логичный выход из ситуации сделать restart. Печально что nginx -t не
> выдает
> > ошибок, в связи с чем вопрос: можно ли как-нибудь идентифицировать
> ситуацию
> > когда reload сломан кроме как по логам?
> >
> > Воспроизвелось на nginx/1.12.2, nginx/1.13.12, CentOS Linux release
> 7.5.1804
> >
>
> У сигналов обратной связи нет, поэтому необходимо всегда смотреть логи.
>


если в лог упала ошибка, можно же как-то сделать, чтобы эту же ошибку
транслировать в код выхода reload-а ?


>
> --
> Валентин Бартенев
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180815/9c42d93f/attachment.html>

From vbart на nginx.com  Wed Aug 15 18:12:20 2018
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Wed, 15 Aug 2018 21:12:20 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INGB0LTQtdC70LDRgtGMIHJlbG9hZCA=?=
 =?UTF-8?B?0L/RgNC4INC90LXQutC+0YLQvtGA0YvRhSDQuNC30LzQtdC90LXQvdC40Y8=?=
 =?UTF-8?B?0YUgbGlzdGVu?=
In-Reply-To: <CAFHpkQH-3=8xH+ineeCR6+kamkeaP+uu=LmY5pi6rNtH6PUhQg@mail.gmail.com>
References: <91dad92b0741dc1f29f94f62ffe4f37a.NginxMailingListRussian@forum.nginx.org>
 <1950543.ptVRA82Chr@vbart-workstation>
 <CAFHpkQH-3=8xH+ineeCR6+kamkeaP+uu=LmY5pi6rNtH6PUhQg@mail.gmail.com>
Message-ID: <1581955.zvlxsCPztj@vbart-workstation>

On Wednesday 15 August 2018 22:46:08 Илья Шипицин wrote:
[..]
> если в лог упала ошибка, можно же как-то сделать, чтобы эту же ошибку
> транслировать в код выхода reload-а ?
> 

reload это команда "kill -s HUP" и у нее код выхода - это успешная
отправка сигнала.

Можете попытаться доработать rc-скрипт и добавить там парсинг лога,
но непонятно сколько времени ждать.  Обработка конфигурации может
занять доли секунды, а может занимать минуты.

Цель же такой доработки сомнительна.  Посмотреть лог после
изменение конфигурации, даже если оно прошло успешно - это
вообще важно.  Там могут возникать ошибки в рамках обработки
запросов новой конфигурацией.

Это плохо когда администраторы не смотрят в логи.

В NGINX Unit такой трудности нет, т.к. он управляется через HTTP
интерфейс и там любая операция с конфигурацией - это запрос, а
её результат это ответ.  Посылать же сигнал, а затем парсить
лог - выглядит как костыль.

--
Валентин Бартенев

From gmm на csdoc.com  Wed Aug 15 18:19:48 2018
From: gmm на csdoc.com (Gena Makhomed)
Date: Wed, 15 Aug 2018 21:19:48 +0300
Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INGB0LTQtdC70LDRgtGMIHJlbG9hZCA=?=
 =?UTF-8?B?0L/RgNC4INC90LXQutC+0YLQvtGA0YvRhSDQuNC30LzQtdC90LXQvdC40Y8=?=
 =?UTF-8?B?0YUgbGlzdGVu?=
In-Reply-To: <91dad92b0741dc1f29f94f62ffe4f37a.NginxMailingListRussian@forum.nginx.org>
References: <91dad92b0741dc1f29f94f62ffe4f37a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <4902d603-f19c-1bcc-eaa2-c2082d6b9e48@csdoc.com>

On 15.08.2018 8:24, simonovbs wrote:

> # systemctl reload nginx

> можно ли как-нибудь идентифицировать ситуацию
> когда reload сломан кроме как по логам?

Без логов - никак.

Можно попробовать сделать

# service nginx check-reload

Если nginx установлен из официального репозитория nginx.org,
тогда в каталоге /usr/libexec/initscripts/legacy-actions/nginx
есть скрипт check-reload который и будет делать примерно то что надо.

-- 
Best regards,
  Gena


From chipitsine на gmail.com  Thu Aug 16 04:43:32 2018
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 16 Aug 2018 09:43:32 +0500
Subject: =?UTF-8?B?UmU6INCd0LXQstC+0LfQvNC+0LbQvdC+INGB0LTQtdC70LDRgtGMIHJlbG9hZCA=?=
 =?UTF-8?B?0L/RgNC4INC90LXQutC+0YLQvtGA0YvRhSDQuNC30LzQtdC90LXQvdC40Y8=?=
 =?UTF-8?B?0YUgbGlzdGVu?=
In-Reply-To: <1581955.zvlxsCPztj@vbart-workstation>
References: <91dad92b0741dc1f29f94f62ffe4f37a.NginxMailingListRussian@forum.nginx.org>
 <1950543.ptVRA82Chr@vbart-workstation>
 <CAFHpkQH-3=8xH+ineeCR6+kamkeaP+uu=LmY5pi6rNtH6PUhQg@mail.gmail.com>
 <1581955.zvlxsCPztj@vbart-workstation>
Message-ID: <CAFHpkQFk=z4k7W04Rk7aFYoxv4cRSsFseSXynBQedgB1F-4R3Q@mail.gmail.com>

ср, 15 авг. 2018 г. в 23:12, Валентин Бартенев <vbart на nginx.com>:

> On Wednesday 15 August 2018 22:46:08 Илья Шипицин wrote:
> [..]
> > если в лог упала ошибка, можно же как-то сделать, чтобы эту же ошибку
> > транслировать в код выхода reload-а ?
> >
>
> reload это команда "kill -s HUP" и у нее код выхода - это успешная
> отправка сигнала.
>
> Можете попытаться доработать rc-скрипт и добавить там парсинг лога,
> но непонятно сколько времени ждать.  Обработка конфигурации может
> занять доли секунды, а может занимать минуты.
>
> Цель же такой доработки сомнительна.  Посмотреть лог после
> изменение конфигурации, даже если оно прошло успешно - это
> вообще важно.  Там могут возникать ошибки в рамках обработки
> запросов новой конфигурацией.
>
> Это плохо когда администраторы не смотрят в логи.
>


у нас эти штуки робот делает.

проверку успешности в reload в робот заложили, искусственный интеллект
"посмотри логи" нет.
я понимаю про отправку сигнала. я про другое. у nginx есть четко
обозначенная ошибка (в приведенном примере),
он пишет ее в лог. сигналы это ведь не  единственный IPC механизм. можно
ведь задействовать другой механизм,
который бы позволил тому, что делает reload, понять, что все пошло не так ?


грубо, вы предлагаете администратору посмотреть лог. ок, пусть его смотрит
сам nginx, когда отправляет сигнал ?
отправил, понял, что кроме как по логу нельзя понять, ошибка или нет,
пошел, посмотрел лог, и потом уже вернул статус.

зачем на плечи человека перекладывать то, что может сделать машина




>
> В NGINX Unit такой трудности нет, т.к. он управляется через HTTP
> интерфейс и там любая операция с конфигурацией - это запрос, а
> её результат это ответ.  Посылать же сигнал, а затем парсить
> лог - выглядит как костыль.
>
> --
> Валентин Бартенев
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180816/71f0e149/attachment-0001.html>

From nginx-forum на forum.nginx.org  Thu Aug 16 10:00:36 2018
From: nginx-forum на forum.nginx.org (Dmytro Lavryk)
Date: Thu, 16 Aug 2018 06:00:36 -0400
Subject: =?UTF-8?B?bGltaXQgcmVxIHpvbmUg0LTQu9GPINC+0LTQvdC+0LPQviBzZXJ2ZXI=?=
Message-ID: <c8f1b5153e8ea59f90a196d28aa51a09.NginxMailingListRussian@forum.nginx.org>

Может я просто логику как-то не понимаю?
На машине много сайтов. limit_req_zone прописываем только в http - в итоге
когда ввожу ограничения - под них попадают те. кто выбирает их по ВСЕМ
сайтам, а мне бы нужно только вот для конкретного.

Надеюсь понятно описал...

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


From nginx-forum на forum.nginx.org  Thu Aug 16 10:58:11 2018
From: nginx-forum на forum.nginx.org (Dmytro Lavryk)
Date: Thu, 16 Aug 2018 06:58:11 -0400
Subject: =?UTF-8?B?UmU6IGxpbWl0IHJlcSB6b25lINC00LvRjyDQvtC00L3QvtCz0L4gc2VydmVy?=
In-Reply-To: <c8f1b5153e8ea59f90a196d28aa51a09.NginxMailingListRussian@forum.nginx.org>
References: <c8f1b5153e8ea59f90a196d28aa51a09.NginxMailingListRussian@forum.nginx.org>
Message-ID: <d2f4cadfc83a736d23db71e5eba93d98.NginxMailingListRussian@forum.nginx.org>

И тут же сам кажется понял:
limit_req_zone $binary_remote_addr$server_name zone=....

составной ключик нам поможет. Сорри за беспокойство.

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


From nginx на kinetiksoft.com  Thu Aug 16 13:13:39 2018
From: nginx на kinetiksoft.com (=?UTF-8?B?0JjQstCw0L0=?=)
Date: Thu, 16 Aug 2018 16:13:39 +0300
Subject: =?UTF-8?B?UmU6IHVuaXQ6INC80LXRhdCw0L3QuNC30Lwg0L7Qv9GA0LXQtNC10LvQtdC90Lg=?=
 =?UTF-8?B?0Y8g0LDQtNGA0LXRgdCwINC60LvQuNC10L3RgtCwINGC0LjQv9CwIHJlYWxp?=
 =?UTF-8?B?cCDQuCDQv9C10YDQtdC00LDRh9CwINC30LDQs9C+0LvQvtCy0LrQvtCy?=
In-Reply-To: <2168474.s7RRUIZoAF@vbart-laptop>
References: <a94b98e1-5110-82b3-bf0c-27bdc773b400@kinetiksoft.com>
 <2168474.s7RRUIZoAF@vbart-laptop>
Message-ID: <827a67f6-3bd9-9b70-39bf-09621761d948@kinetiksoft.com>

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

Кажется, до этого я отправил личное письмо. Исправляю и отвечаю в рассылку.

09.08.2018 10:37, Валентин Бартенев пишет:

> On Wednesday, 8 August 2018 22:53:41 MSK Иван wrote:
>> Здравствуйте!
>>
>> Правильно ли я понимаю, что сейчас unit не умеет передавать в
>> $_SERVER['REMOTE_ADDR']   ip клиента, а не проксирующего nginx?
>> Переделывать весь наш код, чтоб брал IP из другого заголовка будет жестко.
> Да, туда в настоящий момент передается информация из сокета.
>
> Я бы сейчас решил эту задачу маленькой прослойкой в виде небольшого php
> скрипта, который заменяет содержимое $_SERVER['REMOTE_ADDR'] из HTTP_
> заголовка, а далее выполняет уже основной скрипт, запрошенный.  Так не
> потребуется вносить каких-либо изменений в остальной код, а прослойку
> в бущуем можно будет просто убрать.

Пока что держимся на php-fpm. У нас много мелких микросервисов, везде
внедрять эту прослойку - руководство не поймет.

>> Планируется ли это исправить? Когда примерно? Сейчас это единственный
>> для меня блокирующий недостаток для внедрения unit массово в продакшен.
> Насколько я понимаю, некое подобие realip модуля решило бы Вашу задачу?
>
Конкретно с адресом бы решило. Но это необходимо, но совсем не
достаточно. Например, совершенно точно будет нехватать возможности
задать $_server[script_(file)name]. Очень многие продукты используют
ЧПУ, соотвественно без задания script_(file)name веб-сервером не
обойтись. PATH_INFO туда же.

Или даже не ЧПУ, у на видеостриминговый сервис. Мы отадаём плейлсты (*.m3u8) через пыху (x-accell-redirect). Как это реализовать, не задавая SCRIPT_FILENAME?
 

>> Так же интересно, когда планируется ввести возможность передавать вы
>> пыху любые заголовки массива $_SERVER, а не только HTTP_*. Это
>> собственно является решением и предыдущего вопроса.
> Сейчас это не очень простая задача.  Сама по себе возможность задавать
> массив $_SERVER не представляет сложности, но вряд ли будет полезно
> указывать там какие-то константы.  А что-то более осмысленное требует
> уже реализовывать поддержку переменных или какой-то похожий механизм.
> Возможно где-то к концу года, в начале следующего мы что-то подобное
> сделаем.
>
Пока что, похоже, без этого unit в прод не зайдет. Может можно "на
скорую руку" переменные вида
$_SERVER['HTTP_UNIT_VARNAME'] передавать в $_SERVER['VARNAME'] для PHP?
Это бы решило вопрос.

С уважением, Иван.

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

From vbart на nginx.com  Thu Aug 16 14:44:45 2018
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 16 Aug 2018 17:44:45 +0300
Subject: =?UTF-8?B?UmU6IHVuaXQ6INC80LXRhdCw0L3QuNC30Lwg0L7Qv9GA0LXQtNC10LvQtdC90Lg=?=
 =?UTF-8?B?0Y8g0LDQtNGA0LXRgdCwINC60LvQuNC10L3RgtCwINGC0LjQv9CwIHJlYWxp?=
 =?UTF-8?B?cCDQuCDQv9C10YDQtdC00LDRh9CwINC30LDQs9C+0LvQvtCy0LrQvtCy?=
In-Reply-To: <827a67f6-3bd9-9b70-39bf-09621761d948@kinetiksoft.com>
References: <a94b98e1-5110-82b3-bf0c-27bdc773b400@kinetiksoft.com>
 <2168474.s7RRUIZoAF@vbart-laptop>
 <827a67f6-3bd9-9b70-39bf-09621761d948@kinetiksoft.com>
Message-ID: <2198572.7BK3MGWudA@vbart-workstation>

On Thursday 16 August 2018 16:13:39 Иван wrote:
> Здравствуйте!
> 
> Кажется, до этого я отправил личное письмо. Исправляю и отвечаю в рассылку.
> 
> 09.08.2018 10:37, Валентин Бартенев пишет:
> 
> > On Wednesday, 8 August 2018 22:53:41 MSK Иван wrote:
> >> Здравствуйте!
> >>
> >> Правильно ли я понимаю, что сейчас unit не умеет передавать в
> >> $_SERVER['REMOTE_ADDR']   ip клиента, а не проксирующего nginx?
> >> Переделывать весь наш код, чтоб брал IP из другого заголовка будет жестко.
> > Да, туда в настоящий момент передается информация из сокета.
> >
> > Я бы сейчас решил эту задачу маленькой прослойкой в виде небольшого php
> > скрипта, который заменяет содержимое $_SERVER['REMOTE_ADDR'] из HTTP_
> > заголовка, а далее выполняет уже основной скрипт, запрошенный.  Так не
> > потребуется вносить каких-либо изменений в остальной код, а прослойку
> > в бущуем можно будет просто убрать.
> 
> Пока что держимся на php-fpm. У нас много мелких микросервисов, везде
> внедрять эту прослойку - руководство не поймет.
> 

Проблема понятна, пока что скорого решения нет.


> >> Планируется ли это исправить? Когда примерно? Сейчас это единственный
> >> для меня блокирующий недостаток для внедрения unit массово в продакшен.
> > Насколько я понимаю, некое подобие realip модуля решило бы Вашу задачу?
> >
> Конкретно с адресом бы решило. Но это необходимо, но совсем не
> достаточно. Например, совершенно точно будет нехватать возможности
> задать $_server[script_(file)name]. Очень многие продукты используют
> ЧПУ, соотвественно без задания script_(file)name веб-сервером не
> обойтись. PATH_INFO туда же.
> 
> Или даже не ЧПУ, у на видеостриминговый сервис. Мы отадаём плейлсты (*.m3u8) через пыху (x-accell-redirect). Как это реализовать, не задавая SCRIPT_FILENAME?

У PHP приложений есть опция "script", которая и задает SCRIPT_FILENAME.
С WordPress и его ЧПУ прекрасно работает уже сейчас.


>  
> 
> >> Так же интересно, когда планируется ввести возможность передавать вы
> >> пыху любые заголовки массива $_SERVER, а не только HTTP_*. Это
> >> собственно является решением и предыдущего вопроса.
> > Сейчас это не очень простая задача.  Сама по себе возможность задавать
> > массив $_SERVER не представляет сложности, но вряд ли будет полезно
> > указывать там какие-то константы.  А что-то более осмысленное требует
> > уже реализовывать поддержку переменных или какой-то похожий механизм.
> > Возможно где-то к концу года, в начале следующего мы что-то подобное
> > сделаем.
> >
> Пока что, похоже, без этого unit в прод не зайдет. Может можно "на
> скорую руку" переменные вида
> $_SERVER['HTTP_UNIT_VARNAME'] передавать в $_SERVER['VARNAME'] для PHP?
> Это бы решило вопрос.

Кто угодно может послать какие угодно заголовки, так что это будет просто
небезопасно.  Предполагается, что значения в $_SERVER, которые начинаются
не с префикса "HTTP_", пришли не напрямую от клиента и более менее безопасны.

--
Валентин Бартенев

From nginx-forum на forum.nginx.org  Fri Aug 17 10:34:35 2018
From: nginx-forum на forum.nginx.org (mrpsycho)
Date: Fri, 17 Aug 2018 06:34:35 -0400
Subject: =?UTF-8?B?UmU6INCU0L7QutGD0LzQtdC90YLQsNGG0LjRjyDQvdCwINCy0LvQvtC20LXQvdC9?=
 =?UTF-8?B?0YvQtSBsb2NhdGlvbg==?=
In-Reply-To: <20111014094632.GB97305@nginx.com>
References: <20111014094632.GB97305@nginx.com>
Message-ID: <00e05413c88fa0bf0de032343bc489f0.NginxMailingListRussian@forum.nginx.org>

прошу простить за некрофилию.... но, документация появилась? 
очень уж непонятно зачем нужна эта вложенность, если нельзя написать что-то
типа такого:

location / {
    uwsgi_pass api_wsgi_server;
    include /etc/nginx/uwsgi_params;
 
    location api/auth2/login {
      limit_req zone=reqzoneone;
    }
}

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


From kpoxa на kpoxa.net  Fri Aug 17 15:25:38 2018
From: kpoxa на kpoxa.net (kpoxa)
Date: Fri, 17 Aug 2018 18:25:38 +0300
Subject: =?UTF-8?B?UmU6INCU0L7QutGD0LzQtdC90YLQsNGG0LjRjyDQvdCwINCy0LvQvtC20LXQvdC9?=
 =?UTF-8?B?0YvQtSBsb2NhdGlvbg==?=
In-Reply-To: <00e05413c88fa0bf0de032343bc489f0.NginxMailingListRussian@forum.nginx.org>
References: <20111014094632.GB97305@nginx.com>
 <00e05413c88fa0bf0de032343bc489f0.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CABL5twAueGyFzoQhFuX5mg-RFXqaMtrYqs8CSdwk-SwTuxWz4g@mail.gmail.com>

В документации написано, что в / вкладывать нельзя

17 августа 2018 г., 13:34 пользователь mrpsycho
<nginx-forum на forum.nginx.org> написал:
> прошу простить за некрофилию.... но, документация появилась?
> очень уж непонятно зачем нужна эта вложенность, если нельзя написать что-то
> типа такого:
>
> location / {
>     uwsgi_pass api_wsgi_server;
>     include /etc/nginx/uwsgi_params;
>
>     location api/auth2/login {
>       limit_req zone=reqzoneone;
>     }
> }
>
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,216689,280903#msg-280903
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From mdounin на mdounin.ru  Fri Aug 17 15:58:17 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Fri, 17 Aug 2018 18:58:17 +0300
Subject: =?UTF-8?B?UmU6INCU0L7QutGD0LzQtdC90YLQsNGG0LjRjyDQvdCwINCy0LvQvtC20LXQvdC9?=
 =?UTF-8?B?0YvQtSBsb2NhdGlvbg==?=
In-Reply-To: <00e05413c88fa0bf0de032343bc489f0.NginxMailingListRussian@forum.nginx.org>
References: <20111014094632.GB97305@nginx.com>
 <00e05413c88fa0bf0de032343bc489f0.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180817155817.GW56558@mdounin.ru>

Hello!

On Fri, Aug 17, 2018 at 06:34:35AM -0400, mrpsycho wrote:

> прошу простить за некрофилию.... но, документация появилась? 
> очень уж непонятно зачем нужна эта вложенность, если нельзя написать что-то
> типа такого:
> 
> location / {
>     uwsgi_pass api_wsgi_server;
>     include /etc/nginx/uwsgi_params;
>  
>     location api/auth2/login {
>       limit_req zone=reqzoneone;
>     }
> }

Такого написать нельзя, потому что префикс "api/auth2/login" не 
является частью префикса "/".  Если на самом деле имелось ввиду 
"/api/...", то можно написать что-то типа такого:

location / {
    uwsgi_pass api_wsgi_server;
    include /etc/nginx/uwsgi_params;

    location /api/auth2/login {
      limit_req zone=reqzoneone;
      uwsgi_pass api_wsgi_server;
    }
}

При этом во вложенный location наследуются все настройки (поэтому 
не надо второй раз включать uwsgi_params) кроме собственно 
обработчика (поэтому надо продублировать uwsgi_pass, если 
обработка нужна такая же).

Документация есть тут:

http://nginx.org/ru/docs/http/ngx_http_core_module.html#location

Она, впрочем, довольно скромная, и сводится к тому, что location'ы 
могут быть вложенными.

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin на mdounin.ru  Fri Aug 17 15:59:12 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Fri, 17 Aug 2018 18:59:12 +0300
Subject: =?UTF-8?B?UmU6INCU0L7QutGD0LzQtdC90YLQsNGG0LjRjyDQvdCwINCy0LvQvtC20LXQvdC9?=
 =?UTF-8?B?0YvQtSBsb2NhdGlvbg==?=
In-Reply-To: <CABL5twAueGyFzoQhFuX5mg-RFXqaMtrYqs8CSdwk-SwTuxWz4g@mail.gmail.com>
References: <20111014094632.GB97305@nginx.com>
 <00e05413c88fa0bf0de032343bc489f0.NginxMailingListRussian@forum.nginx.org>
 <CABL5twAueGyFzoQhFuX5mg-RFXqaMtrYqs8CSdwk-SwTuxWz4g@mail.gmail.com>
Message-ID: <20180817155912.GX56558@mdounin.ru>

Hello!

On Fri, Aug 17, 2018 at 06:25:38PM +0300, kpoxa wrote:

> В документации написано, что в / вкладывать нельзя

Вы ошибаетесь, такого там не написано.

-- 
Maxim Dounin
http://mdounin.ru/

From vadim.lazovskiy на gmail.com  Mon Aug 20 08:50:35 2018
From: vadim.lazovskiy на gmail.com (Vadim Lazovskiy)
Date: Mon, 20 Aug 2018 11:50:35 +0300
Subject: SLES 15 nginx repo
Message-ID: <CAL-L5YC1WB+eL0-jub8jSfJNXd+qRSV-=OZH+Dt=HX-7tGv2HQ@mail.gmail.com>

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

Можно вас попросить добавить сборку для SLES 15?

Спасибо.

-- 
WBR,
Vadim Lazovskiy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20180820/31803a30/attachment.html>

From nginx-forum на forum.nginx.org  Mon Aug 20 14:36:03 2018
From: nginx-forum на forum.nginx.org (actionmanager)
Date: Mon, 20 Aug 2018 10:36:03 -0400
Subject: =?UTF-8?B?0JTQvtCx0LDQstC40YLRjCDQv9GA0L7QstC10YDQutGDIG5naW54IC10IGFkZCBo?=
 =?UTF-8?B?ZWFkZXIgIjoi?=
Message-ID: <41ec4f414ce2a7be8c66aac17dddebea.NginxMailingListRussian@forum.nginx.org>

Здравствуйте, проксирую https трафик через proxy_pass https://....

Возникла ошибка в Chrome, в Firefox работает:

ERR_SPDY_PROTOCOL_ERROR


Долго искал причину, учитывая что в одном браузере работает, а в другом нет.
Как всегда всё банально :) опечатка в конфиге.


Добавляю http заголовок:

       add_header 'Cache-Host:' 'sun';

debug log:

2018/08/20 16:08:19 [debug] 28446#0: *121 http2 output header: "cache-host::
sun"


Причина в ":"

Возможно ли добавить проверку в add_header, если строка заканчивается на
":", то nginx -t отображал бы ошибку ?

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


From pavel2000 на ngs.ru  Mon Aug 20 18:25:36 2018
From: pavel2000 на ngs.ru (Pavel)
Date: Tue, 21 Aug 2018 01:25:36 +0700
Subject: secure_link + realip + if
Message-ID: <web-104056413@mx63.intranet.ru>

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

Спасибо за Nginx!

В процессе использования появился вопрос по совместному 
использованию
модулей ngx_http_secure_link_module и 
ngx_http_realip_module, с использованием
проверки доступа через if (Да, "if is evil", но есть ли 
другой способ?).

Ранее модуль ngx_http_secure_link_module использовался для 
проверки
доступа в самостоятельной конфигурации, без realip_module.
Теперь сервис переезжает за дополнительный прокси в целях 
защиты от DDOS,
и для получения реального айпи браузера добавился 
ngx_http_realip_module.

Проблема в следущем: если в одном локейшне используются 
два вышеуказанных
модуля + директива if, то переопределение remote_addr не 
происходит.
Если if не использовать - переопределение работает.


Тестовая конфигурация:

user www-data;
worker_processes  1;

error_log  /var/log/nginx/tst.error.log notice;
pid        /var/run/nginx.tst.pid;

events {
     worker_connections  1024;
     # multi_accept on;
}

http {
     include  /etc/nginx/mime.types;
     access_log /var/log/nginx/tst.access.log;


server {
     listen 127.0.0.1:80;
     server_name vhost;

     root /tmp;

     location / {
         set_real_ip_from 127.0.0.1/32;
         real_ip_header X-Forwarded-For;

         secure_link $arg_st;
         secure_link_md5 "${remote_addr}_$uri";
         if ($secure_link = "") {
             return 403;
         }

         add_header X-App-Secure-Uri $uri always;
         add_header X-App-Secure-St $arg_st always;
         add_header X-App-Secure-Addr $remote_addr always;
         add_header X-App-Secure-RealIP 
$realip_remote_addr always;
         add_header X-Forwarded-For $http_x_forwarded_for 
always;
     }
}

}

nginx -c /tmp/nginx.tst.cfg
kill `cat /var/run/nginx.tst.pid`


Тестовый файл:

echo "tst.txt" > /tmp/tst.txt


При закомментированном if имеем ожидаемый ответ с 
переопределением remote_addr, что видно по заголовку 
X-App-Secure-Addr в ответе:

# curl -v -H "Host: vhost" -H "X-Forwarded-For: 8.8.8.8" 
 http://127.0.0.1/tst.txt
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
> GET /tst.txt HTTP/1.1
> Host: vhost
> User-Agent: curl/7.57.0
> Accept: */*
> X-Forwarded-For: 8.8.8.8
>
< HTTP/1.1 200 OK
< Server: nginx/1.10.3
< Date: Mon, 20 Aug 2018 17:51:31 GMT
< Content-Type: text/plain
< Content-Length: 8
< Last-Modified: Mon, 20 Aug 2018 17:47:59 GMT
< Connection: keep-alive
< ETag: "5b7afecf-8"
< X-App-Secure-Uri: /tst.txt
< X-App-Secure-Addr: 8.8.8.8
< X-App-Secure-RealIP: 127.0.0.1
< X-Forwarded-For: 8.8.8.8
< Accept-Ranges: bytes
<
tst.txt
* Connection #0 to host 127.0.0.1 left intact


Если разкомментировать if, то что-то ломается.
Судя по заголовкам ответа, переопределение значения 
remote_addr не происходит,
и в модуле secure_link также используется IP подключения, 
а не из заголовка X-Forwarded-For.
Модуль secure_link разрешает доступ, если подпись 
сформирована для 127.0.0.1

# echo -n "127.0.0.1_/tst.txt" | openssl md5 -binary | 
openssl base64 | tr +/ -_ | tr -d =
AEfp-bT-tHrEfZN8lwDJGQ

# curl -v -H "Host: vhost" -H "X-Forwarded-For: 8.8.8.8" 
 http://127.0.0.1/tst.txt?st=AEfp-bT-tHrEfZN8lwDJGQ
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
> GET /tst.txt?st=AEfp-bT-tHrEfZN8lwDJGQ HTTP/1.1
> Host: vhost
> User-Agent: curl/7.57.0
> Accept: */*
> X-Forwarded-For: 8.8.8.8
>
< HTTP/1.1 200 OK
< Server: nginx/1.10.3
< Date: Mon, 20 Aug 2018 18:05:09 GMT
< Content-Type: text/plain
< Content-Length: 8
< Last-Modified: Mon, 20 Aug 2018 17:47:59 GMT
< Connection: keep-alive
< ETag: "5b7afecf-8"
< X-App-Secure-Uri: /tst.txt
< X-App-Secure-St: AEfp-bT-tHrEfZN8lwDJGQ
< X-App-Secure-Addr: 127.0.0.1
< X-App-Secure-RealIP: 127.0.0.1
< X-Forwarded-For: 8.8.8.8
< Accept-Ranges: bytes
<
tst.txt
* Connection #0 to host 127.0.0.1 left intact

Ожидалось, что доступ будет разрешаться для IP 8.8.8.8, 
значение которого
передается через X-Forwarded-For. Этого не происходит:


# echo -n "8.8.8.8_/tst.txt" | openssl md5 -binary | 
openssl base64 | tr +/ -_ | tr -d =
WEpfZcYFo9shAa3_pwtACw


# curl -v -H "Host: vhost" -H "X-Forwarded-For: 8.8.8.8" 
 http://127.0.0.1/tst.txt?st=WEpfZcYFo9shAa3_pwtACw
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
> GET /tst.txt?st=WEpfZcYFo9shAa3_pwtACw HTTP/1.1
> Host: vhost
> User-Agent: curl/7.57.0
> Accept: */*
> X-Forwarded-For: 8.8.8.8
>
< HTTP/1.1 403 Forbidden
< Server: nginx/1.10.3
< Date: Mon, 20 Aug 2018 18:07:14 GMT
< Content-Type: text/html
< Content-Length: 169
< Connection: keep-alive
< X-App-Secure-Uri: /tst.txt
< X-App-Secure-St: WEpfZcYFo9shAa3_pwtACw
< X-App-Secure-Addr: 127.0.0.1
< X-App-Secure-RealIP: 127.0.0.1
< X-Forwarded-For: 8.8.8.8
<
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.10.3</center>
</body>
</html>
* Connection #0 to host 127.0.0.1 left intact

Какие будут рекомендации?

Спасибо.

From mdounin на mdounin.ru  Wed Aug 22 01:28:39 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 22 Aug 2018 04:28:39 +0300
Subject: secure_link + realip + if
In-Reply-To: <web-104056413@mx63.intranet.ru>
References: <web-104056413@mx63.intranet.ru>
Message-ID: <20180822012839.GY56558@mdounin.ru>

Hello!

On Tue, Aug 21, 2018 at 01:25:36AM +0700, Pavel wrote:

> В процессе использования появился вопрос по совместному 
> использованию
> модулей ngx_http_secure_link_module и 
> ngx_http_realip_module, с использованием
> проверки доступа через if (Да, "if is evil", но есть ли 
> другой способ?).
> 
> Ранее модуль ngx_http_secure_link_module использовался для 
> проверки
> доступа в самостоятельной конфигурации, без realip_module.
> Теперь сервис переезжает за дополнительный прокси в целях 
> защиты от DDOS,
> и для получения реального айпи браузера добавился 
> ngx_http_realip_module.
> 
> Проблема в следущем: если в одном локейшне используются 
> два вышеуказанных
> модуля + директива if, то переопределение remote_addr не 
> происходит.
> Если if не использовать - переопределение работает.

[...]

> server {
>      listen 127.0.0.1:80;
>      server_name vhost;
> 
>      root /tmp;
> 
>      location / {
>          set_real_ip_from 127.0.0.1/32;
>          real_ip_header X-Forwarded-For;
> 
>          secure_link $arg_st;
>          secure_link_md5 "${remote_addr}_$uri";
>          if ($secure_link = "") {
>              return 403;
>          }

В случае, если модуль realip включён на уровне location, он 
работает после окончательного выбора конфигурации, частью какового 
выбора являются директивы модуля rewrite.  В результате в такой 
конфигурации $remote_addr будет использоваться до переопределения 
модулем realip.

Кроме того, ещё не изменённое значение переменной $remote_addr 
закэшируется при первом обращении 
(https://trac.nginx.org/nginx/ticket/603#comment:1),
и в результате будет казаться, что адрес клиента не переопределён 
(на самом деле - переопределён, и скажем allow/deny сработают 
правильно).

[...]

> Какие будут рекомендации?

Наиболее простое и правильное решение - указать set_real_ip_from на 
уровне server.  Тогда адрес клиента будет переопределяться сразу 
после чтения заголовков запроса, и проблемы не будет.

-- 
Maxim Dounin
http://mdounin.ru/

From pavel2000 на ngs.ru  Wed Aug 22 05:06:31 2018
From: pavel2000 на ngs.ru (Pavel)
Date: Wed, 22 Aug 2018 12:06:31 +0700
Subject: secure_link + realip + if
In-Reply-To: <20180822012839.GY56558@mdounin.ru>
References: <web-104056413@mx63.intranet.ru>
 <20180822012839.GY56558@mdounin.ru>
Message-ID: <web-104127533@mx63.intranet.ru>

On Wed, 22 Aug 2018 04:28:39 +0300 Maxim Dounin 
<mdounin на mdounin.ru> wrote:

> Hello!
> 
> В случае, если модуль realip включён на уровне location, 
> он  работает после окончательного выбора конфигурации, 
> частью какового  выбора являются директивы модуля rewrite.  
> В результате в такой конфигурации $remote_addr будет использоваться до 
> переопределения модулем realip.

Понятно, спасибо за разъяснение!

From nginx-forum на forum.nginx.org  Wed Aug 22 11:49:10 2018
From: nginx-forum на forum.nginx.org (Gurd)
Date: Wed, 22 Aug 2018 07:49:10 -0400
Subject: =?UTF-8?B?MzAxIFJlZGlyZWN0INGBIC5odG1sLyDQvdCwLmh0bWw=?=
Message-ID: <f675b62cc3673ce661cf31ae6f33e176.NginxMailingListRussian@forum.nginx.org>

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

Не известно откуда yandex берёт такие url со слэшем в конце
http://site.ru/145-yumor.html/  у нас таких нет.
Подскажите пожалуйста пожно ли делать 301 редирект на без слеша
http://site.ru/145-yumor.html

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


From nginx-forum на forum.nginx.org  Wed Aug 22 11:51:47 2018
From: nginx-forum на forum.nginx.org (Dmitry WD)
Date: Wed, 22 Aug 2018 07:51:47 -0400
Subject: =?UTF-8?B?Tmdpbngg0L7RgtC00LDQtdGCINC60LvQuNC10L3RgtGDIDUwMiwg0L3QviDQv9C+?=
 =?UTF-8?B?0LvRg9GH0LDQtdGCINC+0YIgYmFja2VuZCA0MDE=?=
Message-ID: <71c6ccd87f738b9e6340c9e18b7284b3.NginxMailingListRussian@forum.nginx.org>

Добрый день.

Столкнулись с проблемой - при попытке загрузить файл, не авторизовавшись,
backend отвечает 401, но nginx отдает клиенту 502.
Но если например сделать запрос без отправки файла, но с отправкой формы,
nginx отдает как и надо 401.

Пока предположение такое:
Для всех запросов на backend работает защитник, который из всех данных
загружает и смотрит только заголовки.
Если заголовки не содержат верный токен доступа то запросу отдаётся 401 и на
этом конец.
В запросе POST через nginx идут данные, килобайты, мегабайты и т.д.
Nginx получает их в буфер и пытается отправить на backend, но сразу после
отправки заголовков получает 401.
А так как не отправил все данные и их backend отказался читать считает что
backe-end недоступен.

Такое может быть?
И главное как сделать так чтобы nginx отдавал клиенту 401?

Спасибо

-- 
С уважением,
Dmitry WD

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


From nginx-forum на forum.nginx.org  Thu Aug 23 09:26:19 2018
From: nginx-forum на forum.nginx.org (clgs)
Date: Thu, 23 Aug 2018 05:26:19 -0400
Subject: =?UTF-8?B?0J3QtSDRgNCw0LHQvtGC0LDQtdGCICRodHRwIHggINCyINC60L7QvdGC0LXQutGB?=
 =?UTF-8?B?0YLQtSBodHRwLCDQsCDQuNC80LXQvdC90L4g0LIgZ2Vv?=
Message-ID: <8e1a766aa3deb6ac8d0abb30d00d64d8.NginxMailingListRussian@forum.nginx.org>

Привет.
Не смог найти информацию в каком контексте работают глобальные переменные.
Подскажите почему  $http_x_my_header не работает в данном случае?

http{
        ....
       geo $MY_HEADER {
                default "default";
                192.168.0.11/32 "user1";
                192.168.0.12/32 "user2";
                192.168.0.13/32 "user3";
                192.168.0.99/32 $http_x_my_header;
        }
        .....
        server {
                .....
        }
}

В случае если REMOTE_ADDR 192.168.0.99, то $MY_HEADER является пустой
строкой, при этом сам заголовок HTTP-X-MY-HEADER присутствует.

При компиляции конфига, nginx ошибок не выдаёт.

nginx/1.6.2

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


From mdounin на mdounin.ru  Thu Aug 23 14:26:20 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 23 Aug 2018 17:26:20 +0300
Subject: =?UTF-8?B?UmU6IE5naW54INC+0YLQtNCw0LXRgiDQutC70LjQtdC90YLRgyA1MDIsINC90L4g?=
 =?UTF-8?B?0L/QvtC70YPRh9Cw0LXRgiDQvtGCIGJhY2tlbmQgNDAx?=
In-Reply-To: <71c6ccd87f738b9e6340c9e18b7284b3.NginxMailingListRussian@forum.nginx.org>
References: <71c6ccd87f738b9e6340c9e18b7284b3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180823142619.GC56558@mdounin.ru>

Hello!

On Wed, Aug 22, 2018 at 07:51:47AM -0400, Dmitry WD wrote:

> Столкнулись с проблемой - при попытке загрузить файл, не авторизовавшись,
> backend отвечает 401, но nginx отдает клиенту 502.
> Но если например сделать запрос без отправки файла, но с отправкой формы,
> nginx отдает как и надо 401.
> 
> Пока предположение такое:
> Для всех запросов на backend работает защитник, который из всех данных
> загружает и смотрит только заголовки.
> Если заголовки не содержат верный токен доступа то запросу отдаётся 401 и на
> этом конец.
> В запросе POST через nginx идут данные, килобайты, мегабайты и т.д.
> Nginx получает их в буфер и пытается отправить на backend, но сразу после
> отправки заголовков получает 401.
> А так как не отправил все данные и их backend отказался читать считает что
> backe-end недоступен.
> 
> Такое может быть?
> И главное как сделать так чтобы nginx отдавал клиенту 401?

Вероятнее всего проблема в том, что бэкенд, возвращая 401, не 
делает lingering close, а просто закрывает соединение.  В результе 
nginx'у вслед за ответом улетает RST, и ответа nginx просто не 
получает.  Лечится это только на стороне бэкенда.

Всё, что можно было выжать из работы с такими бэкендами на стороне 
nginx'а - уже выжато, о чём можно прочитать в тикете тут: 
https://trac.nginx.org/nginx/ticket/1037.  Если вдруг на бэкенде 
guncorn - там же есть ссылка, по которой можно пойти и настучать 
по голове авторам.

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin на mdounin.ru  Thu Aug 23 14:56:50 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 23 Aug 2018 17:56:50 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0YDQsNCx0L7RgtCw0LXRgiAkaHR0cCB4ICDQsiDQutC+0L3RgtC1?=
 =?UTF-8?B?0LrRgdGC0LUgaHR0cCwg0LAg0LjQvNC10L3QvdC+INCyIGdlbw==?=
In-Reply-To: <8e1a766aa3deb6ac8d0abb30d00d64d8.NginxMailingListRussian@forum.nginx.org>
References: <8e1a766aa3deb6ac8d0abb30d00d64d8.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180823145650.GD56558@mdounin.ru>

Hello!

On Thu, Aug 23, 2018 at 05:26:19AM -0400, clgs wrote:

> Привет.
> Не смог найти информацию в каком контексте работают глобальные переменные.
> Подскажите почему  $http_x_my_header не работает в данном случае?
> 
> http{
>         ....
>        geo $MY_HEADER {
>                 default "default";
>                 192.168.0.11/32 "user1";
>                 192.168.0.12/32 "user2";
>                 192.168.0.13/32 "user3";
>                 192.168.0.99/32 $http_x_my_header;
>         }
>         .....
>         server {
>                 .....
>         }
> }
> 
> В случае если REMOTE_ADDR 192.168.0.99, то $MY_HEADER является пустой
> строкой, при этом сам заголовок HTTP-X-MY-HEADER присутствует.

Если где-либо можно использовать переменные - об этом явно 
написано в документации.  В содержимом блока geo переменные 
не поддерживаются, соответственно в $MY_HEADER при запросе от 
192.168.0.99 должна получиться сторока "$http_x_my_header".

Если нужно получить значение переменной - воспользуйтесь 
дополнительно директивой map.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Fri Aug 24 12:32:45 2018
From: nginx-forum на forum.nginx.org (Dmitry WD)
Date: Fri, 24 Aug 2018 08:32:45 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INC+0YLQtNCw0LXRgiDQutC70LjQtdC90YLRgyA1MDIsINC90L4g?=
 =?UTF-8?B?0L/QvtC70YPRh9Cw0LXRgiDQvtGCIGJhY2tlbmQgNDAx?=
In-Reply-To: <20180823142619.GC56558@mdounin.ru>
References: <20180823142619.GC56558@mdounin.ru>
Message-ID: <4b7d316abba2755f13c7fe7c3e7df107.NginxMailingListRussian@forum.nginx.org>

Добрый день.

По дампу трафика разрыва соединения не происходит.
Проблема проявляется только если отправлять запрос POST с файлом любого
размера методом multipart-form.
Проблема проявляется только если в запросе нет верного токена доступа в
заголовке.
Для верных токенов доступа всё работает отлично.
На стороне back-end для не верного токена доступа считывается только
заголовок запроса, проверяется токен, если он не верный, тело запроса НЕ
читается и идёт ответ 401.
На этот ответ nginx реагирует как на "сломанный" back-end и отвечает 502.
Так же, стоит заметить что скорость ответа backend очень быстрая и
изменяется микросекундами.

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


From mdounin на mdounin.ru  Sun Aug 26 10:47:55 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Sun, 26 Aug 2018 13:47:55 +0300
Subject: =?UTF-8?B?UmU6IE5naW54INC+0YLQtNCw0LXRgiDQutC70LjQtdC90YLRgyA1MDIsINC90L4g?=
 =?UTF-8?B?0L/QvtC70YPRh9Cw0LXRgiDQvtGCIGJhY2tlbmQgNDAx?=
In-Reply-To: <4b7d316abba2755f13c7fe7c3e7df107.NginxMailingListRussian@forum.nginx.org>
References: <20180823142619.GC56558@mdounin.ru>
 <4b7d316abba2755f13c7fe7c3e7df107.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180826104755.GI56558@mdounin.ru>

Hello!

On Fri, Aug 24, 2018 at 08:32:45AM -0400, Dmitry WD wrote:

> По дампу трафика разрыва соединения не происходит.

Покажите, пожалуйста, tcpdump между nginx'ом и бэкендом.  Заодно 
было бы неплохо увидеть собственно логи nginx'а.

> Проблема проявляется только если отправлять запрос POST с файлом любого
> размера методом multipart-form.
> Проблема проявляется только если в запросе нет верного токена доступа в
> заголовке.
> Для верных токенов доступа всё работает отлично.
> На стороне back-end для не верного токена доступа считывается только
> заголовок запроса, проверяется токен, если он не верный, тело запроса НЕ
> читается и идёт ответ 401.

Ещё раз: невозможно не читать тело запроса.  Если оно есть - его 
надо читать (и выкидывать, если оно не нужно), иначе на ту сторону 
уйдёт RST и отправленный ранее ответ будет потерян ещё до того, 
как nginx его получит из ядра.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Tue Aug 28 14:49:42 2018
From: nginx-forum на forum.nginx.org (Dmitry WD)
Date: Tue, 28 Aug 2018 10:49:42 -0400
Subject: =?UTF-8?B?UmU6IE5naW54INC+0YLQtNCw0LXRgiDQutC70LjQtdC90YLRgyA1MDIsINC90L4g?=
 =?UTF-8?B?0L/QvtC70YPRh9Cw0LXRgiDQvtGCIGJhY2tlbmQgNDAx?=
In-Reply-To: <20180826104755.GI56558@mdounin.ru>
References: <20180826104755.GI56558@mdounin.ru>
Message-ID: <611d04dd746a09fa2613d5a20e4f77a3.NginxMailingListRussian@forum.nginx.org>

Максим, спасибо за ответ.
А можете дать ссылку на то место в RFC где сказано что тело запроса надо
дочитывать полностью до конца и нельзя прерываться и начинать отвечать?
Кстати, через unix сокет ситуация аналогична, при работе с unix или tcp
сокетом чтение из сокета и запись в сокет разделены.
Нет необходимости дочитывать сокет до конца чтобы начать в него писать.

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


From mdounin на mdounin.ru  Tue Aug 28 15:23:09 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 28 Aug 2018 18:23:09 +0300
Subject: =?UTF-8?B?UmU6IE5naW54INC+0YLQtNCw0LXRgiDQutC70LjQtdC90YLRgyA1MDIsINC90L4g?=
 =?UTF-8?B?0L/QvtC70YPRh9Cw0LXRgiDQvtGCIGJhY2tlbmQgNDAx?=
In-Reply-To: <611d04dd746a09fa2613d5a20e4f77a3.NginxMailingListRussian@forum.nginx.org>
References: <20180826104755.GI56558@mdounin.ru>
 <611d04dd746a09fa2613d5a20e4f77a3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20180828152309.GQ56558@mdounin.ru>

Hello!

On Tue, Aug 28, 2018 at 10:49:42AM -0400, Dmitry WD wrote:

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

Такого - нигде не написано, потому что это не соответствует 
действительности.  А вот ответить и закрыть соединения, не читая 
тело - нельзя.  Подробно про это рассказано в RFC 7230, 
https://tools.ietf.org/html/rfc7230#section-6.6:

   If a server performs an immediate close of a TCP connection, there is
   a significant risk that the client will not be able to read the last
   HTTP response.  If the server receives additional data from the
   client on a fully closed connection, such as another request that was
   sent by the client before receiving the server's response, the
   server's TCP stack will send a reset packet to the client;
   unfortunately, the reset packet might erase the client's
   unacknowledged input buffers before they can be read and interpreted
   by the client's HTTP parser.

   To avoid the TCP reset problem, servers typically close a connection
   in stages.  First, the server performs a half-close by closing only
   the write side of the read/write connection.  The server then
   continues to read from the connection until it receives a
   corresponding close by the client, or until the server is reasonably
   certain that its own TCP stack has received the client's
   acknowledgement of the packet(s) containing the server's last
   response.  Finally, the server fully closes the connection.

   It is unknown whether the reset problem is exclusive to TCP or might
   also be found in other transport connection protocols.

Ту же цитату и ссылку на RFC вы можете найти в тикете, ссылку на 
который я давал в исходном ответе.

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin на mdounin.ru  Tue Aug 28 15:47:56 2018
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 28 Aug 2018 18:47:56 +0300
Subject: nginx-1.15.3
Message-ID: <20180828154756.GT56558@mdounin.ru>

Изменения в nginx 1.15.3                                          28.08.2018

    *) Добавление: теперь TLSv1.3 можно использовать с BoringSSL.

    *) Добавление: директива ssl_early_data, сейчас доступна при
       использовании BoringSSL.

    *) Добавление: директивы keepalive_timeout и keepalive_requests в блоке
       upstream.

    *) Исправление: модуль ngx_http_dav_module при копировании файла поверх
       существующего файла с помощью метода COPY не обнулял целевой файл.

    *) Исправление: модуль ngx_http_dav_module при перемещении файла между
       файловыми системами с помощью метода MOVE устанавливал нулевые права
       доступа на результирующий файл и не сохранял время изменения файла.

    *) Исправление: модуль ngx_http_dav_module при копировании файла с
       помощью метода COPY для результирующего файла использовал права
       доступа по умолчанию.

    *) Изменение: некоторые клиенты могли не работать при использовании
       HTTP/2; ошибка появилась в 1.13.5.

    *) Исправление: nginx не собирался с LibreSSL 2.8.0.


-- 
Maxim Dounin
http://nginx.org/