From nginx-forum на forum.nginx.org  Wed Apr  1 08:05:29 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Wed, 01 Apr 2020 04:05:29 -0400
Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?=
In-Reply-To: <4e0c8966-573d-ff3a-f723-f7c9dc6d5ae7@grid.net.ru>
References: <4e0c8966-573d-ff3a-f723-f7c9dc6d5ae7@grid.net.ru>
Message-ID: <006165dffdcb529dc301b90d7eb7dbb5.NginxMailingListRussian@forum.nginx.org>

Valery Kholodkov Wrote:
-------------------------------------------------------
> Вот и я спрашиваю: зачем тебе FastCGI если есть HTTP?

кстати, что конкретно имеется ввиду под HTTP? О каком именно
программировании тут речь идёт?

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


From red-fox0 на ya.ru  Wed Apr  1 08:32:58 2020
From: red-fox0 на ya.ru (fox)
Date: Wed, 1 Apr 2020 15:32:58 +0700
Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?=
In-Reply-To: <006165dffdcb529dc301b90d7eb7dbb5.NginxMailingListRussian@forum.nginx.org>
References: <4e0c8966-573d-ff3a-f723-f7c9dc6d5ae7@grid.net.ru>
 <006165dffdcb529dc301b90d7eb7dbb5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <6047024f-d591-6b81-bba0-dd642bfeff9b@ya.ru>

Обычный текстовый протокол (HTTP/1.1). Наверняка есть готовые библиотеки
на с/с++ для парсинга запросов.

Можно и самому написать: https://tools.ietf.org/html/rfc2616

greenwar пишет:
> Valery Kholodkov Wrote:
> -------------------------------------------------------
>> Вот и я спрашиваю: зачем тебе FastCGI если есть HTTP?
> 
> кстати, что конкретно имеется ввиду под HTTP? О каком именно
> программировании тут речь идёт?
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287500,287512#msg-287512
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 


From chipitsine на gmail.com  Wed Apr  1 08:42:08 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 1 Apr 2020 13:42:08 +0500
Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?=
In-Reply-To: <6047024f-d591-6b81-bba0-dd642bfeff9b@ya.ru>
References: <4e0c8966-573d-ff3a-f723-f7c9dc6d5ae7@grid.net.ru>
 <006165dffdcb529dc301b90d7eb7dbb5.NginxMailingListRussian@forum.nginx.org>
 <6047024f-d591-6b81-bba0-dd642bfeff9b@ya.ru>
Message-ID: <CAFHpkQHJiESWZM4Kp=WvyThLjCaU5XLCwtiVcuZJdE2A0PWB5Q@mail.gmail.com>

чего только нет, вот например  https://github.com/civetweb/civetweb
встраиваемый веб сервер

ср, 1 апр. 2020 г. в 13:33, fox <red-fox0 на ya.ru>:

> Обычный текстовый протокол (HTTP/1.1). Наверняка есть готовые библиотеки
> на с/с++ для парсинга запросов.
>
> Можно и самому написать: https://tools.ietf.org/html/rfc2616
>
> greenwar пишет:
> > Valery Kholodkov Wrote:
> > -------------------------------------------------------
> >> Вот и я спрашиваю: зачем тебе FastCGI если есть HTTP?
> >
> > кстати, что конкретно имеется ввиду под HTTP? О каком именно
> > программировании тут речь идёт?
> >
> > Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,287500,287512#msg-287512
> >
> > _______________________________________________
> > 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
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200401/4b0e1718/attachment.htm>

From nginx-forum на forum.nginx.org  Wed Apr  1 10:14:16 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Wed, 01 Apr 2020 06:14:16 -0400
Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?=
In-Reply-To: <6047024f-d591-6b81-bba0-dd642bfeff9b@ya.ru>
References: <6047024f-d591-6b81-bba0-dd642bfeff9b@ya.ru>
Message-ID: <f0e74c89f2827cd63ce563c3207dc33a.NginxMailingListRussian@forum.nginx.org>

ну например в Nginx же есть поддержка ws: https://habr.com/ru/post/171757/
это никак не упростит задачу?

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


From valery+nginxru на grid.net.ru  Wed Apr  1 11:06:27 2020
From: valery+nginxru на grid.net.ru (Valery Kholodkov)
Date: Wed, 1 Apr 2020 13:06:27 +0200
Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?=
In-Reply-To: <006165dffdcb529dc301b90d7eb7dbb5.NginxMailingListRussian@forum.nginx.org>
References: <4e0c8966-573d-ff3a-f723-f7c9dc6d5ae7@grid.net.ru>
 <006165dffdcb529dc301b90d7eb7dbb5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <b2e1e659-da20-c811-349e-03a32113db6d@grid.net.ru>

FastCGI использовался в прошлом для ускорения комуникации между 
веб-сервером и апп-сервером.

Сейчас, когда можно с легкостью написать событийно-ориентированное 
приложение отвечающее по HTTP, преимущество использования FastCGI 
представляется сомнительным.

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

Если есть задача сделать  приложение на C++ и подключить к nginx с 
помощью libfcgi, то это несложно. А вот выжать из него максимум 
производительности, реализовать поддерджку всех фич HTTP и поддерживать 
его в течении длительного времени -- это гораздо сложнее, чем на то же 
самом node.js.

On 01-04-20 10:05, greenwar wrote:
> Valery Kholodkov Wrote:
> -------------------------------------------------------
>> Вот и я спрашиваю: зачем тебе FastCGI если есть HTTP?
> 
> кстати, что конкретно имеется ввиду под HTTP? О каком именно
> программировании тут речь идёт?


-- 
Val

From bgx на protva.ru  Wed Apr  1 11:58:31 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Wed, 1 Apr 2020 14:58:31 +0300
Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?=
In-Reply-To: <b2e1e659-da20-c811-349e-03a32113db6d@grid.net.ru>
References: <4e0c8966-573d-ff3a-f723-f7c9dc6d5ae7@grid.net.ru>
 <006165dffdcb529dc301b90d7eb7dbb5.NginxMailingListRussian@forum.nginx.org>
 <b2e1e659-da20-c811-349e-03a32113db6d@grid.net.ru>
Message-ID: <20200401115831.GG8478@sie.protva.ru>

On Wed, Apr 01, 2020 at 01:06:27PM +0200, Valery Kholodkov wrote:
> FastCGI использовался в прошлом для ускорения комуникации между веб-сервером
> и апп-сервером.

 Разве? Запросы, упакованные в FastCGI, бегут по сети между серверами
 быстрее, чем те же запросы в виде HTTP?

> Сейчас, когда можно с легкостью написать событийно-ориентированное
> приложение отвечающее по HTTP, преимущество использования FastCGI
> представляется сомнительным.

 Возможность писать простые однопоточные приложения как раз является
 преимуществом. К тому же запрос в FastCGI доступен приложению в
 уже разложенном по хедерам виде.

> Более того, nginx не поддерживает мультиплексирования запросов через одно
> соединение FastCGI, то есть преимущество использования FastCGI сводится
> всего лишь к компресии заголовков и возможности не принимать тело запроса.

 Компрессия заголовков в FastCGI, это не ошибка?

> Если есть задача сделать  приложение на C++ и подключить к nginx с помощью
> libfcgi, то это несложно. А вот выжать из него максимум производительности,
> реализовать поддерджку всех фич HTTP и поддерживать его в течении
> длительного времени -- это гораздо сложнее, чем на то же самом node.js.

 1. О каких фичах http речь?
 2. Где можно выжать максимум производительности, за счёт чего?
 3. Приведите примеры, pls, где что-то выжимается большим трудом на FastCGI
 и легко и просто на Node.js.
 Спасибо.
-- 
 Eugene Berdnikov

From valery+nginxru на grid.net.ru  Wed Apr  1 12:54:20 2020
From: valery+nginxru на grid.net.ru (Valery Kholodkov)
Date: Wed, 1 Apr 2020 14:54:20 +0200
Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?=
In-Reply-To: <20200401115831.GG8478@sie.protva.ru>
References: <4e0c8966-573d-ff3a-f723-f7c9dc6d5ae7@grid.net.ru>
 <006165dffdcb529dc301b90d7eb7dbb5.NginxMailingListRussian@forum.nginx.org>
 <b2e1e659-da20-c811-349e-03a32113db6d@grid.net.ru>
 <20200401115831.GG8478@sie.protva.ru>
Message-ID: <6c15065f-85ae-a7c8-3eed-9440758dd312@grid.net.ru>

On 01-04-20 13:58, Evgeniy Berdnikov wrote:
> On Wed, Apr 01, 2020 at 01:06:27PM +0200, Valery Kholodkov wrote:
>> FastCGI использовался в прошлом для ускорения комуникации между веб-сервером
>> и апп-сервером.
> 
>   Разве? Запросы, упакованные в FastCGI, бегут по сети между серверами
>   быстрее, чем те же запросы в виде HTTP?

См. https://en.wikipedia.org/wiki/FastCGI -> Implementation details

>> Сейчас, когда можно с легкостью написать событийно-ориентированное
>> приложение отвечающее по HTTP, преимущество использования FastCGI
>> представляется сомнительным.
> 
>   Возможность писать простые однопоточные приложения как раз является
>   преимуществом. К тому же запрос в FastCGI доступен приложению в
>   уже разложенном по хедерам виде.

А как насчет кук, параметров, разбора тела, поддержки сессий? libfcgi-то 
отдает только голый запрос.

Далее, зачем в 2020 году писать многопоточное приложение с кучей 
блокирующих библиотек, если можно писать приложение с кучей 
неблокирующих библиотек?

>> Если есть задача сделать  приложение на C++ и подключить к nginx с помощью
>> libfcgi, то это несложно. А вот выжать из него максимум производительности,
>> реализовать поддерджку всех фич HTTP и поддерживать его в течении
>> длительного времени -- это гораздо сложнее, чем на то же самом node.js.
> 
>   1. О каких фичах http речь?
>   2. Где можно выжать максимум производительности, за счёт чего?
>   3. Приведите примеры, pls, где что-то выжимается большим трудом на FastCGI
>   и легко и просто на Node.js.

Давайте решим этот спор следующим образом: если Вам требуется некоторое 
приложение на FastCGI и C++, я готов Вам его разработать и поддерживать, 
если Вы готовы за это заплатить.

-- 
Val

From bgx на protva.ru  Wed Apr  1 13:35:10 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Wed, 1 Apr 2020 16:35:10 +0300
Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?=
In-Reply-To: <6c15065f-85ae-a7c8-3eed-9440758dd312@grid.net.ru>
References: <4e0c8966-573d-ff3a-f723-f7c9dc6d5ae7@grid.net.ru>
 <006165dffdcb529dc301b90d7eb7dbb5.NginxMailingListRussian@forum.nginx.org>
 <b2e1e659-da20-c811-349e-03a32113db6d@grid.net.ru>
 <20200401115831.GG8478@sie.protva.ru>
 <6c15065f-85ae-a7c8-3eed-9440758dd312@grid.net.ru>
Message-ID: <20200401133510.GA2630@sie.protva.ru>

On Wed, Apr 01, 2020 at 02:54:20PM +0200, Valery Kholodkov wrote:
> On 01-04-20 13:58, Evgeniy Berdnikov wrote:
> > On Wed, Apr 01, 2020 at 01:06:27PM +0200, Valery Kholodkov wrote:
> > > FastCGI использовался в прошлом для ускорения комуникации между веб-сервером
> > > и апп-сервером.
> > 
> >   Разве? Запросы, упакованные в FastCGI, бегут по сети между серверами
> >   быстрее, чем те же запросы в виде HTTP?
> 
> См. https://en.wikipedia.org/wiki/FastCGI -> Implementation details

 Где там ответ на заданный вопрос? Я его не вижу и уверен, что его быть
 не может.

 Вы действительно считаете, что пакеты по сети бегают с разной скоростью
 в зависимости от их содержимого?

> > > Сейчас, когда можно с легкостью написать событийно-ориентированное
> > > приложение отвечающее по HTTP, преимущество использования FastCGI
> > > представляется сомнительным.
> > 
> >   Возможность писать простые однопоточные приложения как раз является
> >   преимуществом. К тому же запрос в FastCGI доступен приложению в
> >   уже разложенном по хедерам виде.
> 
> А как насчет кук, параметров, разбора тела, поддержки сессий? libfcgi-то
> отдает только голый запрос.

 А никак, к протоколу доставки данных это отношения не имеет.
 Любая либа будет работать с куками одинаково эффективно, как бы содержимое
 хедера Cookie ни было к ней доставлено.

> Далее, зачем в 2020 году писать многопоточное приложение с кучей блокирующих
> библиотек, если можно писать приложение с кучей неблокирующих библиотек?

 Ваша самоцель демонстрировать свою крутизну как программера и получать
 побольше зарплату, или же писать код с минимальным расходом ресурсов?

> > > Если есть задача сделать  приложение на C++ и подключить к nginx с помощью
> > > libfcgi, то это несложно. А вот выжать из него максимум производительности,
> > > реализовать поддерджку всех фич HTTP и поддерживать его в течении
> > > длительного времени -- это гораздо сложнее, чем на то же самом node.js.
> > 
> >   1. О каких фичах http речь?
> >   2. Где можно выжать максимум производительности, за счёт чего?
> >   3. Приведите примеры, pls, где что-то выжимается большим трудом на FastCGI
> >   и легко и просто на Node.js.
> 
> Давайте решим этот спор следующим образом: если Вам требуется некоторое
> приложение на FastCGI и C++, я готов Вам его разработать и поддерживать,
> если Вы готовы за это заплатить.

 Понятно, Вы не способны аргументировать свои утверждения, всё сводится
 к тому, что за какую-то техническую чушь хотите денег. Вопрос закрыт.
-- 
 Eugene Berdnikov

From nginx-forum на forum.nginx.org  Wed Apr  1 13:38:55 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Wed, 01 Apr 2020 09:38:55 -0400
Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?=
In-Reply-To: <b2e1e659-da20-c811-349e-03a32113db6d@grid.net.ru>
References: <b2e1e659-da20-c811-349e-03a32113db6d@grid.net.ru>
Message-ID: <57024a610f8a2b7843cebdd2f3879505.NginxMailingListRussian@forum.nginx.org>

я так то весьма далёк от NodeJS, но подозреваю, что он не сильно сложнее
обычного JS, который, по сути, сильно проще того же C/C++...
Поэтому спрошу глупость: он разве компилирует код заранее?
Я вот сомневаюсь, что при всех его "кучи неблокирующих библиотек" (откуда
они кстати возьмутся, если их нет на C??) и супер-заточенности под HTTP, что
при всём при этом он НЕ сольёт C/C++...

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


From valery+nginxru на grid.net.ru  Wed Apr  1 13:49:58 2020
From: valery+nginxru на grid.net.ru (Valery Kholodkov)
Date: Wed, 1 Apr 2020 15:49:58 +0200
Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?=
In-Reply-To: <20200401133510.GA2630@sie.protva.ru>
References: <4e0c8966-573d-ff3a-f723-f7c9dc6d5ae7@grid.net.ru>
 <006165dffdcb529dc301b90d7eb7dbb5.NginxMailingListRussian@forum.nginx.org>
 <b2e1e659-da20-c811-349e-03a32113db6d@grid.net.ru>
 <20200401115831.GG8478@sie.protva.ru>
 <6c15065f-85ae-a7c8-3eed-9440758dd312@grid.net.ru>
 <20200401133510.GA2630@sie.protva.ru>
Message-ID: <18074b71-9363-ce11-4108-7cfc027ed258@grid.net.ru>

On 01-04-20 15:35, Evgeniy Berdnikov wrote:
>> Далее, зачем в 2020 году писать многопоточное приложение с кучей блокирующих
>> библиотек, если можно писать приложение с кучей неблокирующих библиотек?
> 
>   Ваша самоцель демонстрировать свою крутизну как программера и получать
>   побольше зарплату, или же писать код с минимальным расходом ресурсов?

Не понял, что тут с чем и как связано?

>> Давайте решим этот спор следующим образом: если Вам требуется некоторое
>> приложение на FastCGI и C++, я готов Вам его разработать и поддерживать,
>> если Вы готовы за это заплатить.
> 
>   Понятно, Вы не способны аргументировать свои утверждения, всё сводится
>   к тому, что за какую-то техническую чушь хотите денег. Вопрос закрыт.

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

-- 
Val

From chipitsine на gmail.com  Wed Apr  1 13:59:59 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 1 Apr 2020 18:59:59 +0500
Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?=
In-Reply-To: <18074b71-9363-ce11-4108-7cfc027ed258@grid.net.ru>
References: <4e0c8966-573d-ff3a-f723-f7c9dc6d5ae7@grid.net.ru>
 <006165dffdcb529dc301b90d7eb7dbb5.NginxMailingListRussian@forum.nginx.org>
 <b2e1e659-da20-c811-349e-03a32113db6d@grid.net.ru>
 <20200401115831.GG8478@sie.protva.ru>
 <6c15065f-85ae-a7c8-3eed-9440758dd312@grid.net.ru>
 <20200401133510.GA2630@sie.protva.ru>
 <18074b71-9363-ce11-4108-7cfc027ed258@grid.net.ru>
Message-ID: <CAFHpkQGrHfJyPeAyL1raPHsd8NtmTyqhgaTT6NF5aYCwSyA=1A@mail.gmail.com>

ср, 1 апр. 2020 г. в 18:50, Valery Kholodkov <valery+nginxru на grid.net.ru>:

> On 01-04-20 15:35, Evgeniy Berdnikov wrote:
> >> Далее, зачем в 2020 году писать многопоточное приложение с кучей
> блокирующих
> >> библиотек, если можно писать приложение с кучей неблокирующих библиотек?
> >
> >   Ваша самоцель демонстрировать свою крутизну как программера и получать
> >   побольше зарплату, или же писать код с минимальным расходом ресурсов?
>
> Не понял, что тут с чем и как связано?
>
> >> Давайте решим этот спор следующим образом: если Вам требуется некоторое
> >> приложение на FastCGI и C++, я готов Вам его разработать и поддерживать,
> >> если Вы готовы за это заплатить.
> >
> >   Понятно, Вы не способны аргументировать свои утверждения, всё сводится
> >   к тому, что за какую-то техническую чушь хотите денег. Вопрос закрыт.
>
> Нет, я хочу денег за Ваше непонимание в какую техничкую проблему Вы
> ввязались. По-моему, это справедливо.
>


да пусть человек развлекается.
вреда от этого скорее всего никакого.
может польза будет.


>
> --
> Val
> _______________________________________________
> 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/20200401/b0bac551/attachment.htm>

From valery+nginxru на grid.net.ru  Wed Apr  1 14:55:41 2020
From: valery+nginxru на grid.net.ru (Valery Kholodkov)
Date: Wed, 1 Apr 2020 16:55:41 +0200
Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?=
In-Reply-To: <CAFHpkQGrHfJyPeAyL1raPHsd8NtmTyqhgaTT6NF5aYCwSyA=1A@mail.gmail.com>
References: <4e0c8966-573d-ff3a-f723-f7c9dc6d5ae7@grid.net.ru>
 <006165dffdcb529dc301b90d7eb7dbb5.NginxMailingListRussian@forum.nginx.org>
 <b2e1e659-da20-c811-349e-03a32113db6d@grid.net.ru>
 <20200401115831.GG8478@sie.protva.ru>
 <6c15065f-85ae-a7c8-3eed-9440758dd312@grid.net.ru>
 <20200401133510.GA2630@sie.protva.ru>
 <18074b71-9363-ce11-4108-7cfc027ed258@grid.net.ru>
 <CAFHpkQGrHfJyPeAyL1raPHsd8NtmTyqhgaTT6NF5aYCwSyA=1A@mail.gmail.com>
Message-ID: <ba1c3af4-7042-37f2-de8d-357249095b19@grid.net.ru>

On 01-04-20 15:59, Илья Шипицин wrote:
>     Нет, я хочу денег за Ваше непонимание в какую техничкую проблему Вы
>     ввязались. По-моему, это справедливо.
> 
> 
> 
> да пусть человек развлекается.
> вреда от этого скорее всего никакого. > может польза будет.

Точно! Я подумал, возможно он вообще повар или физиотерапевт? Карантин, 
работчий день закончился, а поговорить не с кем. А тут списки рассылки.

-- 
Val

From nginx-forum на forum.nginx.org  Thu Apr  2 03:59:50 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Wed, 01 Apr 2020 23:59:50 -0400
Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?=
In-Reply-To: <20200401133510.GA2630@sie.protva.ru>
References: <20200401133510.GA2630@sie.protva.ru>
Message-ID: <86b35f01b398fce216132bbf5ea37f81.NginxMailingListRussian@forum.nginx.org>

Evgeniy Berdnikov Wrote:
-------------------------------------------------------
> Вопрос закрыт.

не, не, не, это моя тема! Мне то объясните, что к чему ))

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


From nginx-forum на forum.nginx.org  Thu Apr  2 04:21:07 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Thu, 02 Apr 2020 00:21:07 -0400
Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?=
In-Reply-To: <6c15065f-85ae-a7c8-3eed-9440758dd312@grid.net.ru>
References: <6c15065f-85ae-a7c8-3eed-9440758dd312@grid.net.ru>
Message-ID: <1d52a18e0b5b29c1eeaf96adad557b35.NginxMailingListRussian@forum.nginx.org>

Valery Kholodkov Wrote:
-------------------------------------------------------
> Далее, зачем в 2020 году писать многопоточное приложение с кучей 
> блокирующих библиотек, если можно писать приложение с кучей 
> неблокирующих библиотек?

таки откуда возьмутся "неблокирующие библиотеки" где-то, если их в C/C++
нет?

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


From nginx-forum на forum.nginx.org  Thu Apr  2 14:19:59 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Thu, 02 Apr 2020 10:19:59 -0400
Subject: =?UTF-8?Q?backend_=D0=B4=D0=BB=D1=8F_Nginx_+_websockets?=
Message-ID: <f757362faa0d190eb36a87271c2d8a4b.NginxMailingListRussian@forum.nginx.org>

господа, а расскажите пожалуйста про начинку для этого конфига, где Nginx
проксирует вебсокеты?
я вот взял обычный демон, который просто отдаёт:
"HTTP/1.1 200 OK\r\nServer: maputa\r\nContent-Type:
text/html\r\nContent-Length: 7\r\n\r\nWisdom\r\n\r\n"

Подключил конфиг для вебсокета и вуаля - оно работает прям с первого
раза...
Что особенно понравилось - БЕЗ бубнов и магии - ПРОСТО работает!
Так вот вопрос, в сравнении с FastCGI, где надо было кучу всего писать и
обрабатывать, чтобы тот же самый эффект получить, здесь как будет? Ну ведь
всё равно же куки надо обрабатывать? Сессии надо обрабатывать? GET/POST надо
обрабатывать? И т.д.?
В общем, можете расписать принцип работы этой схемы? (а то я первый раз в
вебсокеты залез)
Них*я не понял, но очень интересно! (с)
https://www.youtube.com/watch?v=qSkUuFySwqE

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


From nginx-forum на forum.nginx.org  Thu Apr  2 14:38:16 2020
From: nginx-forum на forum.nginx.org (muxui)
Date: Thu, 02 Apr 2020 10:38:16 -0400
Subject: =?UTF-8?B?THVhINGC0YDQuNCz0LPQtdGAINC/0YDQuCDQt9Cw0L/RgNC+0YHQtT8=?=
Message-ID: <15007b71fa6931d99f513c4289bd4538.NginxMailingListRussian@forum.nginx.org>

Всем привет.
Собственно, интересует, можно-ли как-то создать триггер, который вызывает
Луа при каждом запросе (*by_lua).
Объясню на примере. Есть вот такая разметка:
server {
    	server_name site.ru;
    	listen 443 ssl http2;

    	location / {
    		content_by_lua_file /var/www/test.luac;
    		aio threads;
    	}
    }

Как мы видим - при кажом запросе на site.ru идет отдача test.luac, но мне бы
вот хотелось, чтобы сначала выполнился другой скрипт, типа он сначала
отработает свое (он создает сессию), а потом уже пойдет выполнение
test.luac.
Знаю, что можно написать триггер прям в форме, но у меня будет много бекенда
на Lua, поэтому, везде делать эту писанину - не такая уж и хорошая затея, а
так можно было-бы подключить триггер одной строкой и радоваться на
здоровье.
Буду очень благодарен за помощь.

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


From valery+nginxru на grid.net.ru  Fri Apr  3 15:43:42 2020
From: valery+nginxru на grid.net.ru (Valery Kholodkov)
Date: Fri, 3 Apr 2020 17:43:42 +0200
Subject: =?UTF-8?Q?Re=3A_backend_=D0=B4=D0=BB=D1=8F_Nginx_+_websockets?=
In-Reply-To: <f757362faa0d190eb36a87271c2d8a4b.NginxMailingListRussian@forum.nginx.org>
References: <f757362faa0d190eb36a87271c2d8a4b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <7ac6db42-f799-57f4-41ba-a6716ed58e63@grid.net.ru>

Во-первых, в сравнении не FastCGI, а с libfcgi.

Во-вторых, до веб сокетов мы ещё не дошли, и вообще не дойдем, потому 
что насколько мне известно, FastCGI не умеет апгрейдить протокол.

Так вот в сравнении с libfcgi придется ещё большую кучу писать и 
обрабатывать, потому что то что Вы показали -- это поток байт. Таким 
способом можно сделать сервер-затычку, но чтобы сделать 
полнофункциональный сервер, нужно релизовать ещё список вещей, чтобы 
корректно транспортировать запросы и ответы, в то время как libfcgi из 
коробки уже будет это делать.

On 02-04-20 16:19, greenwar wrote:
> господа, а расскажите пожалуйста про начинку для этого конфига, где Nginx
> проксирует вебсокеты?
> я вот взял обычный демон, который просто отдаёт:
> "HTTP/1.1 200 OK\r\nServer: maputa\r\nContent-Type:
> text/html\r\nContent-Length: 7\r\n\r\nWisdom\r\n\r\n"
> 
> Подключил конфиг для вебсокета и вуаля - оно работает прям с первого
> раза...
> Что особенно понравилось - БЕЗ бубнов и магии - ПРОСТО работает!
> Так вот вопрос, в сравнении с FastCGI, где надо было кучу всего писать и
> обрабатывать, чтобы тот же самый эффект получить, здесь как будет? Ну ведь
> всё равно же куки надо обрабатывать? Сессии надо обрабатывать? GET/POST надо
> обрабатывать? И т.д.?
> В общем, можете расписать принцип работы этой схемы? (а то я первый раз в
> вебсокеты залез)
> Них*я не понял, но очень интересно! (с)
> https://www.youtube.com/watch?v=qSkUuFySwqE


-- 
Val

From nginx-forum на forum.nginx.org  Fri Apr  3 17:13:49 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Fri, 03 Apr 2020 13:13:49 -0400
Subject: =?UTF-8?Q?Re=3A_backend_=D0=B4=D0=BB=D1=8F_Nginx_+_websockets?=
In-Reply-To: <7ac6db42-f799-57f4-41ba-a6716ed58e63@grid.net.ru>
References: <7ac6db42-f799-57f4-41ba-a6716ed58e63@grid.net.ru>
Message-ID: <f3ec978e4e2cf62d66fd2e534ee8c9b5.NginxMailingListRussian@forum.nginx.org>

Valery Kholodkov Wrote:
-------------------------------------------------------
> Во-вторых, до веб сокетов мы ещё не дошли, и вообще не дойдем, потому 
> что насколько мне известно, FastCGI не умеет апгрейдить протокол.

там сейчас вообще нет fastcgi, от слова совсем
ни одной директивы с этим словом

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


From valery+nginxru на grid.net.ru  Fri Apr  3 17:31:51 2020
From: valery+nginxru на grid.net.ru (Valery Kholodkov)
Date: Fri, 3 Apr 2020 19:31:51 +0200
Subject: =?UTF-8?Q?Re=3A_backend_=D0=B4=D0=BB=D1=8F_Nginx_+_websockets?=
In-Reply-To: <f3ec978e4e2cf62d66fd2e534ee8c9b5.NginxMailingListRussian@forum.nginx.org>
References: <7ac6db42-f799-57f4-41ba-a6716ed58e63@grid.net.ru>
 <f3ec978e4e2cf62d66fd2e534ee8c9b5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5cfb83c2-16b9-bbd4-4630-f0a64a5993c3@grid.net.ru>

Алиса, прекрати флудить на форумах из-под анонимного аккаунта!

On 03-04-20 19:13, greenwar wrote:
> Valery Kholodkov Wrote:
> -------------------------------------------------------
>> Во-вторых, до веб сокетов мы ещё не дошли, и вообще не дойдем, потому
>> что насколько мне известно, FastCGI не умеет апгрейдить протокол.
> 
> там сейчас вообще нет fastcgi, от слова совсем
> ни одной директивы с этим словом

-- 
Val

From nginx-forum на forum.nginx.org  Sat Apr  4 03:16:50 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Fri, 03 Apr 2020 23:16:50 -0400
Subject: =?UTF-8?Q?Re=3A_backend_=D0=B4=D0=BB=D1=8F_Nginx_+_websockets?=
In-Reply-To: <5cfb83c2-16b9-bbd4-4630-f0a64a5993c3@grid.net.ru>
References: <5cfb83c2-16b9-bbd4-4630-f0a64a5993c3@grid.net.ru>
Message-ID: <a92ded34d1e5a598cc100a4710a75e01.NginxMailingListRussian@forum.nginx.org>

это ко мне обращение?

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


From nginx-forum на forum.nginx.org  Mon Apr  6 11:17:30 2020
From: nginx-forum на forum.nginx.org (gewisser)
Date: Mon, 06 Apr 2020 07:17:30 -0400
Subject: =?UTF-8?Q?Windows_=D0=B8_upstream_php-cgi=2Eexe?=
Message-ID: <03669627a237ad36fe007cd83923dbe4.NginxMailingListRussian@forum.nginx.org>

Всем привет. Имеем под windows:

run php-cgi.exe -b 127.0.0.1:9001-c php.ini
run php-cgi.exe -b 127.0.0.1:9002-c php.ini
run php-cgi.exe -b 127.0.0.1:9003-c php.ini
run php-cgi.exe -b 127.0.0.1:9004-c php.ini
run php-cgi.exe -b 127.0.0.1:9005-c php.ini

	upstream backend {
		server 127.0.0.1:9001;
		server 127.0.0.1:9002;
		server 127.0.0.1:9003;
		server 127.0.0.1:9004;
		server 127.0.0.1:9005;
	}	

Есть проект в котором скрипт php выполнив определённую работу, должен
продолжить работу в фоне.
Раньше с Apache у меня работал вот этот кусок кода:
https://gist.github.com/bubba-h57/32593b2b970366d24be7

Решил хоть как то заставить это работать с nginx. Для начала попытался
отключить буферизацию ответов FastCGI:
header("X-Accel-Buffering: no");

И ответ стал возвращаться браузеру. 
По логике работы web приложения, в браузере к nginx идут последующие
запросы... и вот тут то возникают для меня непонятки. Следующий запрос как
правило (но не всегда) остаётся в режиме "pending" и остаётся до того как не
истечёт "fastcgi_read_timeout" по умолчанию 60 сек. 

По какой то причине nginx зная, что один из апстримов находится в режиме
ожидания ответа, последующий запрос ставит в очередь на этот апстрим и не
выбирает другой... Чтобы nginx выбрал другой upstream, нужно соединение с
браузером которое может быть keep-alive разорвать. Чтобы разорвать
соединение нужно отправить заголовок header("Connection: close"); который
при любых обстоятельствах не пропускается nginx брвузеру.

Мы можем выставить fastcgi_read_timeout, например в 2 секунды и тогда nginx
закроет по таймауту соединение с апстримом, скрипт успешно выполнит свою
долгую работу в фоне, апстрим будет свободен для приёма сообщений и т.д. 
но! Что если нам реально нужно ждать ответ от апстрима более 2,3,4...100
сек?

Как можно сказать nginx закрыть соединение с fastcgi? А лучше аналогично как
мы через хедеры говорим nginx не буферизовать вывод (X-Accel-Buffering: no),
так же сказать закрыть соединение с апстримом. 

PS.
  Про FPM и fastcgi_finish_request() знаю.

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


From mdounin на mdounin.ru  Mon Apr  6 12:43:07 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 6 Apr 2020 15:43:07 +0300
Subject: =?UTF-8?Q?Re=3A_Windows_=D0=B8_upstream_php-cgi=2Eexe?=
In-Reply-To: <03669627a237ad36fe007cd83923dbe4.NginxMailingListRussian@forum.nginx.org>
References: <03669627a237ad36fe007cd83923dbe4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200406124307.GM20357@mdounin.ru>

Hello!

On Mon, Apr 06, 2020 at 07:17:30AM -0400, gewisser wrote:

> Всем привет. Имеем под windows:
> 
> run php-cgi.exe -b 127.0.0.1:9001-c php.ini
> run php-cgi.exe -b 127.0.0.1:9002-c php.ini
> run php-cgi.exe -b 127.0.0.1:9003-c php.ini
> run php-cgi.exe -b 127.0.0.1:9004-c php.ini
> run php-cgi.exe -b 127.0.0.1:9005-c php.ini
> 
> 	upstream backend {
> 		server 127.0.0.1:9001;
> 		server 127.0.0.1:9002;
> 		server 127.0.0.1:9003;
> 		server 127.0.0.1:9004;
> 		server 127.0.0.1:9005;
> 	}	
> 
> Есть проект в котором скрипт php выполнив определённую работу, должен
> продолжить работу в фоне.
> Раньше с Apache у меня работал вот этот кусок кода:
> https://gist.github.com/bubba-h57/32593b2b970366d24be7
> 
> Решил хоть как то заставить это работать с nginx. Для начала попытался
> отключить буферизацию ответов FastCGI:
> header("X-Accel-Buffering: no");
> 
> И ответ стал возвращаться браузеру. 
> По логике работы web приложения, в браузере к nginx идут последующие
> запросы... и вот тут то возникают для меня непонятки. Следующий запрос как
> правило (но не всегда) остаётся в режиме "pending" и остаётся до того как не
> истечёт "fastcgi_read_timeout" по умолчанию 60 сек. 
> 
> По какой то причине nginx зная, что один из апстримов находится в режиме
> ожидания ответа, последующий запрос ставит в очередь на этот апстрим и не
> выбирает другой... Чтобы nginx выбрал другой upstream, нужно соединение с
> браузером которое может быть keep-alive разорвать. Чтобы разорвать
> соединение нужно отправить заголовок header("Connection: close"); который
> при любых обстоятельствах не пропускается nginx брвузеру.

То, что "один из апстримов находится в режиме ожидания ответа" - в 
общем случае никак не влияет на то, может ли бекенд отвечать на 
другие запросы по другим соединениям.  В норме - может.  Если у 
вас не может - нужно принимать специальные меры, чтобы 
ограничивать соединения к одному бекенду.  В простейшем случае - 
можно использовать least_conn балансировку 
(http://nginx.org/r/least_conn/ru).  В вашем случае, впрочем, это 
не поможет, потому что проблема в другом.

Проблема не в том, что nginx "последующий запрос ставит в очередь 
на этот апстрим и не выбирает другой", проблема в том, что запрос 
к бекенду - не завершён, и соответственно обработка запроса от 
клиента - не завершена.  Очередной запрос от клиента в том же 
соединении по HTTP/1.1 - не будет обрабатываться, пока предыдущий 
не завершён.

> Мы можем выставить fastcgi_read_timeout, например в 2 секунды и тогда nginx
> закроет по таймауту соединение с апстримом, скрипт успешно выполнит свою
> долгую работу в фоне, апстрим будет свободен для приёма сообщений и т.д. 
> но! Что если нам реально нужно ждать ответ от апстрима более 2,3,4...100
> сек?
> 
> Как можно сказать nginx закрыть соединение с fastcgi? А лучше аналогично как
> мы через хедеры говорим nginx не буферизовать вывод (X-Accel-Buffering: no),
> так же сказать закрыть соединение с апстримом. 
> 
> PS.
>   Про FPM и fastcgi_finish_request() знаю.

Чтобы завершить обработку предыдущего запроса - нужно завершить 
запрос в рамках протокола FastCGI, именно это делает 
fastcgi_finish_request().  Все остальные "решения" - это костыли 
той или иной степени опасности и некорректности.

Если fastcgi_finish_request() по какой-то причине не подходит - 
то, вероятно, проще всего будет сделать отдельный location для 
запросов, в которых предполагается долгая обработка "в фоне", и 
выключить там keepalive с помощью директивы keepalive_timeout 
(http://nginx.org/r/keepalive_timeout/ru).

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

From nginx-forum на forum.nginx.org  Mon Apr  6 15:25:37 2020
From: nginx-forum на forum.nginx.org (gewisser)
Date: Mon, 06 Apr 2020 11:25:37 -0400
Subject: =?UTF-8?Q?Re=3A_Windows_=D0=B8_upstream_php-cgi=2Eexe?=
In-Reply-To: <20200406124307.GM20357@mdounin.ru>
References: <20200406124307.GM20357@mdounin.ru>
Message-ID: <42ce03341c98932dce8b4a660084e3af.NginxMailingListRussian@forum.nginx.org>

> Проблема не в том, что nginx "последующий запрос ставит в очередь
> на этот апстрим и не выбирает другой", проблема в том, что запрос
> к бекенду - не завершён, и соответственно обработка запроса от
> клиента - не завершена. Очередной запрос от клиента в том же
> соединении по HTTP/1.1 - не будет обрабатываться, пока предыдущий
> не завершён.

Всё тогда понятно. 

> Если fastcgi_finish_request() по какой-то причине не подходит -
> то, вероятно, проще всего будет сделать отдельный location для
> запросов, в которых предполагается долгая обработка "в фоне", и
> выключить там keepalive с помощью директивы keepalive_timeout
> (http://nginx.org/r/keepalive_timeout/ru).

Да, это можно, но всё же проще браузеру отправить "Connection: close" и
последний разорвёт соединение. Просто запрос может быть долгим, а может быть
нет. Решает бек на определённом этапе работы алгоритма... Я всё что можно
было изгуглил и не нашел как отправить браузеру "Connection: close"  кроме
как модифицировать исходники nginx... )))

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


From nginx-forum на forum.nginx.org  Mon Apr 13 13:17:18 2020
From: nginx-forum на forum.nginx.org (Klark)
Date: Mon, 13 Apr 2020 09:17:18 -0400
Subject: =?UTF-8?B?0J/RgNC4INCy0LrQu9GO0YfQtdC90LjQuCBTU0wgbmdpbngsINGB0LjQu9GM0L0=?=
 =?UTF-8?B?0L4g0YPQv9Cw0LvQsCDRgdC60L7RgNC+0YHRgtGMINGB0LrQsNGH0LjQstCw?=
 =?UTF-8?B?0L3QuNGP?=
Message-ID: <c78f79a56df689a556be9e4ba6cb0796.NginxMailingListRussian@forum.nginx.org>

Такая вот досада.

Стоит сервер с UBUNTU + Nginx, поставил сегодня сертификат от Let's encrypt
и вот что заметил если обычно я мог качать на скорости 10- 12мб после
включения ssl nginx отдает файл максимум на скорости 200-400кб/c .

Беда произошла именно из-за ssl так как я открыл на другом порту простой 80
порт без ssl и через него все на ура выдало максимальные скорости, в чем
может быть проблема?

Сервер: intel core i5 4440S,16GB RAM,1x480GB ssd, 2x2TB HDD SATA 3.

server {

        listen 443 ssl;

        root /var/www/html/files/;
        index index.html index.htm index.nginx-debian.html;
        ssl_certificate /etc/nginx/cert/cert1.pem;
        ssl_certificate_key  /etc/nginx/cert/privkey1.pem;
        server_name filesrv.me;



        location / {
                access_log off;
                mp4;
                mp4_buffer_size 10M; #2
                mp4_max_buffer_size 20M; #4
                access_log off;
                expires max;
                aio off;
                directio 512; 
                output_buffers 1 2M;
                sendfile on;
                tcp_nopush on;
                tcp_nodelay on;
                tcp_nodelay on;
                add_header Cache-Control public;
                open_file_cache max=1000 inactive=900s;
                open_file_cache_valid 360s;
                open_file_cache_min_uses 2;
                open_file_cache_errors off;


   }

}

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


From chipitsine на gmail.com  Mon Apr 13 16:13:02 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 13 Apr 2020 21:13:02 +0500
Subject: =?UTF-8?B?UmU6INCf0YDQuCDQstC60LvRjtGH0LXQvdC40LggU1NMIG5naW54LCDRgdC40Ls=?=
 =?UTF-8?B?0YzQvdC+INGD0L/QsNC70LAg0YHQutC+0YDQvtGB0YLRjCDRgdC60LDRh9C4?=
 =?UTF-8?B?0LLQsNC90LjRjw==?=
In-Reply-To: <c78f79a56df689a556be9e4ba6cb0796.NginxMailingListRussian@forum.nginx.org>
References: <c78f79a56df689a556be9e4ba6cb0796.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQEMB5c36bw6R2vZ7PkSgZLW6trb7Ayw4G1V+ZJP4Z3xWg@mail.gmail.com>

сколько сетевых устройств между клиентом и сервером ? есть ли там
какое-нибудь DPI оборудование от провайдера ?
попробуйте воспроизвести на коротком плече, когда клиент напрямую подключен
в сегмент с сервером

open_file_cache - настройка с нетривиальными побочными эффектами. если вы
ее нагуглили, лучше отключите.

далее вопрос, вы наблюдаете деградацию скорости в клиенте, который стримит
mp4 ? для исключения того, что причина в клиенте, попробуйте скачивать
wget-ом

пн, 13 апр. 2020 г. в 18:17, Klark <nginx-forum на forum.nginx.org>:

> Такая вот досада.
>
> Стоит сервер с UBUNTU + Nginx, поставил сегодня сертификат от Let's encrypt
> и вот что заметил если обычно я мог качать на скорости 10- 12мб после
> включения ssl nginx отдает файл максимум на скорости 200-400кб/c .
>
> Беда произошла именно из-за ssl так как я открыл на другом порту простой 80
> порт без ssl и через него все на ура выдало максимальные скорости, в чем
> может быть проблема?
>
> Сервер: intel core i5 4440S,16GB RAM,1x480GB ssd, 2x2TB HDD SATA 3.
>
> server {
>
>         listen 443 ssl;
>
>         root /var/www/html/files/;
>         index index.html index.htm index.nginx-debian.html;
>         ssl_certificate /etc/nginx/cert/cert1.pem;
>         ssl_certificate_key  /etc/nginx/cert/privkey1.pem;
>         server_name filesrv.me;
>
>
>
>         location / {
>                 access_log off;
>                 mp4;
>                 mp4_buffer_size 10M; #2
>                 mp4_max_buffer_size 20M; #4
>                 access_log off;
>                 expires max;
>                 aio off;
>                 directio 512;
>                 output_buffers 1 2M;
>                 sendfile on;
>                 tcp_nopush on;
>                 tcp_nodelay on;
>                 tcp_nodelay on;
>                 add_header Cache-Control public;
>                 open_file_cache max=1000 inactive=900s;
>                 open_file_cache_valid 360s;
>                 open_file_cache_min_uses 2;
>                 open_file_cache_errors off;
>
>
>    }
>
> }
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,287625,287625#msg-287625
>
> _______________________________________________
> 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/20200413/a11e44c6/attachment.htm>

From nginx-forum на forum.nginx.org  Mon Apr 13 16:35:04 2020
From: nginx-forum на forum.nginx.org (Klark)
Date: Mon, 13 Apr 2020 12:35:04 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQuCDQstC60LvRjtGH0LXQvdC40LggU1NMIG5naW54LCDRgdC40Ls=?=
 =?UTF-8?B?0YzQvdC+INGD0L/QsNC70LAg0YHQutC+0YDQvtGB0YLRjCDRgdC60LDRh9C4?=
 =?UTF-8?B?0LLQsNC90LjRjw==?=
In-Reply-To: <CAFHpkQEMB5c36bw6R2vZ7PkSgZLW6trb7Ayw4G1V+ZJP4Z3xWg@mail.gmail.com>
References: <CAFHpkQEMB5c36bw6R2vZ7PkSgZLW6trb7Ayw4G1V+ZJP4Z3xWg@mail.gmail.com>
Message-ID: <a288c73b8610591799aecc9b15d6e8b1.NginxMailingListRussian@forum.nginx.org>

По поводу DPI я даже попробовал сделать скачивание между двумя локальными
серверами, в ДЦ стоит 2 сервера на Colocation на одном есть такая проблема
на другом нет. При этом скачивая там с одного сервера на другой по https
такая же скорость (Проверял wget'ом). При этом оба сервера стримят mp4 и
конфиг у них идентичный, разница там только в процессоре на том сервере где
все нормально с https процессор немного слабее.

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


From chipitsine на gmail.com  Mon Apr 13 16:39:20 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 13 Apr 2020 21:39:20 +0500
Subject: =?UTF-8?B?UmU6INCf0YDQuCDQstC60LvRjtGH0LXQvdC40LggU1NMIG5naW54LCDRgdC40Ls=?=
 =?UTF-8?B?0YzQvdC+INGD0L/QsNC70LAg0YHQutC+0YDQvtGB0YLRjCDRgdC60LDRh9C4?=
 =?UTF-8?B?0LLQsNC90LjRjw==?=
In-Reply-To: <a288c73b8610591799aecc9b15d6e8b1.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQEMB5c36bw6R2vZ7PkSgZLW6trb7Ayw4G1V+ZJP4Z3xWg@mail.gmail.com>
 <a288c73b8610591799aecc9b15d6e8b1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQGETNjF5y+25xhUSgi8bKTyshFQ7b7fRPCdXpQYFUq2aA@mail.gmail.com>

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

помочь ответить на этот вопрос может созерцание мониторинга процессора,
сети, диска на сервере

пн, 13 апр. 2020 г. в 21:35, Klark <nginx-forum на forum.nginx.org>:

> По поводу DPI я даже попробовал сделать скачивание между двумя локальными
> серверами, в ДЦ стоит 2 сервера на Colocation на одном есть такая проблема
> на другом нет. При этом скачивая там с одного сервера на другой по https
> такая же скорость (Проверял wget'ом). При этом оба сервера стримят mp4 и
> конфиг у них идентичный, разница там только в процессоре на том сервере где
> все нормально с https процессор немного слабее.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,287625,287628#msg-287628
>
> _______________________________________________
> 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/20200413/76fa7474/attachment-0001.htm>

From nginx-forum на forum.nginx.org  Mon Apr 13 17:30:12 2020
From: nginx-forum на forum.nginx.org (Klark)
Date: Mon, 13 Apr 2020 13:30:12 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQuCDQstC60LvRjtGH0LXQvdC40LggU1NMIG5naW54LCDRgdC40Ls=?=
 =?UTF-8?B?0YzQvdC+INGD0L/QsNC70LAg0YHQutC+0YDQvtGB0YLRjCDRgdC60LDRh9C4?=
 =?UTF-8?B?0LLQsNC90LjRjw==?=
In-Reply-To: <CAFHpkQGETNjF5y+25xhUSgi8bKTyshFQ7b7fRPCdXpQYFUq2aA@mail.gmail.com>
References: <CAFHpkQGETNjF5y+25xhUSgi8bKTyshFQ7b7fRPCdXpQYFUq2aA@mail.gmail.com>
Message-ID: <abebb1d6f9e7d981c9dd9f880fec3b83.NginxMailingListRussian@forum.nginx.org>

За этим наблюдаю уже 2 дня. Использую atop,htop и top. Показатели все вроде
отличные, озу используется не более чем на 70%, сетевой канал не нагружен из
доступного 1Гбит используется не более 400мбит, и у всех соеденение в
среднем 2,5 мбит (смотрел через iftop), это как раз та скорость скачивания
через https, процессор при этом на гружен максимум на 40%, сетевые
прерывания правда на одном ядре висят, сетевая встроенная там на материнке
от Asus, очередей не поддерживает но коннектов нет в таком количестве чтобы
в сеть упереться. Кстати соеденений в час пик не более 900 смотрю через
Nginx stats,

Active connections: 815 
server accepts handled requests
 384971 384971 287029 
Reading: 0 Writing: 800 Waiting: 14 

И явно количество тут не причем так как ночью когда Active Connections 10-15
проблема не проходит она стабильна вне зависимости от количества открытых
соединений. 

По дискам тоже не упираюсь так как там так как сами видео на HDD,а
популярные видео на SSD но при этом я специально при скачке брал файлы с
каждого из них то есть в скорость дисков не упираемся, сами же диски
нагружены максимум на 40-45% а SSD в среднем на 30%.


Через Top посмотрел что по процессору там вот такие показатели в час пик

top - 22:30:13 up 20 days,  9:47,  1 user,  load average: 1,03, 1,21, 1,18
Tasks: 142 total,   1 running,  85 sleeping,   0 stopped,   0 zombie
%Cpu(s):  5,9 us,  7,1 sy,  0,0 ni, 67,4 id, 12,5 wa,  0,0 hi,  7,0 si,  0,0
st
KiB Mem : 16285420 total,   196972 free,  3751700 used, 12336748 buff/cache
KiB Swap:  2097148 total,  2069844 free,    27304 used. 12189936 avail Mem

Тут тоже проблем вроде не наблюдается


Уже и не знаю куда копать дальше

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


From alex.hha на gmail.com  Mon Apr 13 17:44:37 2020
From: alex.hha на gmail.com (Alex Domoradov)
Date: Mon, 13 Apr 2020 20:44:37 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQuCDQstC60LvRjtGH0LXQvdC40LggU1NMIG5naW54LCDRgdC40Ls=?=
 =?UTF-8?B?0YzQvdC+INGD0L/QsNC70LAg0YHQutC+0YDQvtGB0YLRjCDRgdC60LDRh9C4?=
 =?UTF-8?B?0LLQsNC90LjRjw==?=
In-Reply-To: <abebb1d6f9e7d981c9dd9f880fec3b83.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQGETNjF5y+25xhUSgi8bKTyshFQ7b7fRPCdXpQYFUq2aA@mail.gmail.com>
 <abebb1d6f9e7d981c9dd9f880fec3b83.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAK90gp72CvUkOtCJRifNVfs-khm-UA5idqt23yVsPt+FO_9Tfg@mail.gmail.com>

> 12,5 wa

я бы сказал, что диск уже захлебывается

On Mon, Apr 13, 2020 at 8:30 PM Klark <nginx-forum на forum.nginx.org> wrote:

> За этим наблюдаю уже 2 дня. Использую atop,htop и top. Показатели все вроде
> отличные, озу используется не более чем на 70%, сетевой канал не нагружен
> из
> доступного 1Гбит используется не более 400мбит, и у всех соеденение в
> среднем 2,5 мбит (смотрел через iftop), это как раз та скорость скачивания
> через https, процессор при этом на гружен максимум на 40%, сетевые
> прерывания правда на одном ядре висят, сетевая встроенная там на материнке
> от Asus, очередей не поддерживает но коннектов нет в таком количестве чтобы
> в сеть упереться. Кстати соеденений в час пик не более 900 смотрю через
> Nginx stats,
>
> Active connections: 815
> server accepts handled requests
>  384971 384971 287029
> Reading: 0 Writing: 800 Waiting: 14
>
> И явно количество тут не причем так как ночью когда Active Connections
> 10-15
> проблема не проходит она стабильна вне зависимости от количества открытых
> соединений.
>
> По дискам тоже не упираюсь так как там так как сами видео на HDD,а
> популярные видео на SSD но при этом я специально при скачке брал файлы с
> каждого из них то есть в скорость дисков не упираемся, сами же диски
> нагружены максимум на 40-45% а SSD в среднем на 30%.
>
>
> Через Top посмотрел что по процессору там вот такие показатели в час пик
>
> top - 22:30:13 up 20 days,  9:47,  1 user,  load average: 1,03, 1,21, 1,18
> Tasks: 142 total,   1 running,  85 sleeping,   0 stopped,   0 zombie
> %Cpu(s):  5,9 us,  7,1 sy,  0,0 ni, 67,4 id, 12,5 wa,  0,0 hi,  7,0 si,
> 0,0
> st
> KiB Mem : 16285420 total,   196972 free,  3751700 used, 12336748 buff/cache
> KiB Swap:  2097148 total,  2069844 free,    27304 used. 12189936 avail Mem
>
> Тут тоже проблем вроде не наблюдается
>
>
> Уже и не знаю куда копать дальше
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,287625,287630#msg-287630
>
> _______________________________________________
> 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/20200413/d79126a9/attachment.htm>

From chipitsine на gmail.com  Mon Apr 13 19:46:05 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 14 Apr 2020 00:46:05 +0500
Subject: =?UTF-8?B?UmU6INCf0YDQuCDQstC60LvRjtGH0LXQvdC40LggU1NMIG5naW54LCDRgdC40Ls=?=
 =?UTF-8?B?0YzQvdC+INGD0L/QsNC70LAg0YHQutC+0YDQvtGB0YLRjCDRgdC60LDRh9C4?=
 =?UTF-8?B?0LLQsNC90LjRjw==?=
In-Reply-To: <CAK90gp72CvUkOtCJRifNVfs-khm-UA5idqt23yVsPt+FO_9Tfg@mail.gmail.com>
References: <CAFHpkQGETNjF5y+25xhUSgi8bKTyshFQ7b7fRPCdXpQYFUq2aA@mail.gmail.com>
 <abebb1d6f9e7d981c9dd9f880fec3b83.NginxMailingListRussian@forum.nginx.org>
 <CAK90gp72CvUkOtCJRifNVfs-khm-UA5idqt23yVsPt+FO_9Tfg@mail.gmail.com>
Message-ID: <CAFHpkQGRHZ3XxiJnEVt5j8evx2TsHBOouyO4BF1=N5UarhFLHA@mail.gmail.com>

пн, 13 апр. 2020 г. в 22:45, Alex Domoradov <alex.hha на gmail.com>:

> > 12,5 wa
>
> я бы сказал, что диск уже захлебывается
>

выглядит так.

но при этом проявляется только на https ?
а покажите top на http ?

насчет мониторинга, пробовали https://www.datadoghq.com/ ?
там история есть


>
> On Mon, Apr 13, 2020 at 8:30 PM Klark <nginx-forum на forum.nginx.org> wrote:
>
>> За этим наблюдаю уже 2 дня. Использую atop,htop и top. Показатели все
>> вроде
>> отличные, озу используется не более чем на 70%, сетевой канал не нагружен
>> из
>> доступного 1Гбит используется не более 400мбит, и у всех соеденение в
>> среднем 2,5 мбит (смотрел через iftop), это как раз та скорость скачивания
>> через https, процессор при этом на гружен максимум на 40%, сетевые
>> прерывания правда на одном ядре висят, сетевая встроенная там на материнке
>> от Asus, очередей не поддерживает но коннектов нет в таком количестве
>> чтобы
>> в сеть упереться. Кстати соеденений в час пик не более 900 смотрю через
>> Nginx stats,
>>
>> Active connections: 815
>> server accepts handled requests
>>  384971 384971 287029
>> Reading: 0 Writing: 800 Waiting: 14
>>
>> И явно количество тут не причем так как ночью когда Active Connections
>> 10-15
>> проблема не проходит она стабильна вне зависимости от количества открытых
>> соединений.
>>
>> По дискам тоже не упираюсь так как там так как сами видео на HDD,а
>> популярные видео на SSD но при этом я специально при скачке брал файлы с
>> каждого из них то есть в скорость дисков не упираемся, сами же диски
>> нагружены максимум на 40-45% а SSD в среднем на 30%.
>>
>>
>> Через Top посмотрел что по процессору там вот такие показатели в час пик
>>
>> top - 22:30:13 up 20 days,  9:47,  1 user,  load average: 1,03, 1,21, 1,18
>> Tasks: 142 total,   1 running,  85 sleeping,   0 stopped,   0 zombie
>> %Cpu(s):  5,9 us,  7,1 sy,  0,0 ni, 67,4 id, 12,5 wa,  0,0 hi,  7,0 si,
>> 0,0
>> st
>> KiB Mem : 16285420 total,   196972 free,  3751700 used, 12336748
>> buff/cache
>> KiB Swap:  2097148 total,  2069844 free,    27304 used. 12189936 avail Mem
>>
>> Тут тоже проблем вроде не наблюдается
>>
>>
>> Уже и не знаю куда копать дальше
>>
>> Posted at Nginx Forum:
>> https://forum.nginx.org/read.php?21,287625,287630#msg-287630
>>
>> _______________________________________________
>> 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
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200414/760d3d92/attachment-0001.htm>

From nginx-forum на forum.nginx.org  Mon Apr 13 21:24:33 2020
From: nginx-forum на forum.nginx.org (Klark)
Date: Mon, 13 Apr 2020 17:24:33 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQuCDQstC60LvRjtGH0LXQvdC40LggU1NMIG5naW54LCDRgdC40Ls=?=
 =?UTF-8?B?0YzQvdC+INGD0L/QsNC70LAg0YHQutC+0YDQvtGB0YLRjCDRgdC60LDRh9C4?=
 =?UTF-8?B?0LLQsNC90LjRjw==?=
In-Reply-To: <CAK90gp72CvUkOtCJRifNVfs-khm-UA5idqt23yVsPt+FO_9Tfg@mail.gmail.com>
References: <CAK90gp72CvUkOtCJRifNVfs-khm-UA5idqt23yVsPt+FO_9Tfg@mail.gmail.com>
Message-ID: <9f781a70bed7fe7643f1eb23668f2f44.NginxMailingListRussian@forum.nginx.org>

Ночью нулевые значения и нет соеденений максимум 10, и при этом все равно
проблема та же

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


From mdounin на mdounin.ru  Tue Apr 14 14:34:28 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 14 Apr 2020 17:34:28 +0300
Subject: nginx-1.17.10
Message-ID: <20200414143428.GM20357@mdounin.ru>

Изменения в nginx 1.17.10                                         14.04.2020

    *) Добавление: директива auth_delay.


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

From denis на webmaster.spb.ru  Wed Apr 15 00:30:33 2020
From: denis на webmaster.spb.ru (denis на webmaster.spb.ru)
Date: Wed, 15 Apr 2020 03:30:33 +0300
Subject: nginx-ldap-auth
Message-ID: <2043571586910309@sas1-2bf44b70450e.qloud-c.yandex.net>

Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200415/b892368a/attachment.htm>

From nginx-forum на forum.nginx.org  Wed Apr 15 21:41:50 2020
From: nginx-forum на forum.nginx.org (edc)
Date: Wed, 15 Apr 2020 17:41:50 -0400
Subject: =?UTF-8?B?TkpTIC0g0J3QtdC/0YDQsNCy0LjQu9GM0L3QvtC1INGH0YLQtdC90LjQtSDRhNCw?=
 =?UTF-8?B?0LnQu9Cw?=
Message-ID: <1a8b7a6c2e839443624e00133b7181a1.NginxMailingListRussian@forum.nginx.org>

Возникла необходимость читать счётчики с сетевых интерфейсов. Метрика
доступна в файле /sys/class/net/eth0/statistics/rx_bytes 
NJS возвращает текущее значение и вдобавок к метрике мусор. Похоже весь файл
читается блоком в 4K. Если тот-же код выполнить в ноде - результат
корректен.  Правильное ли это поведение njs?

Пример кода -  test.js

var fs = require('fs')
var file = fs.readFileSync('/sys/class/net/eth0/statistics/rx_bytes')
var file = fs.writeFileSync('filecopy.txt', file)

Проверка:

stat /sys/class/net/wlp61s0/statistics/rx_bytes

File: /sys/class/net/wlp61s0/statistics/rx_bytes
Size: 4096            Blocks: 0          IO Block: 4096   regular file

njs  test.js
stat filecopy.txt 

File: filecopy.txt
Size: 4096            Blocks: 8          IO Block: 4096   regular file

node test.js
stat filecopy.txt 

File: filecopy.txt
Size: 10              Blocks: 8          IO Block: 4096   regular file

Версии:
njs -v
0.3.9

node -v
v8.10.0

Проверял на Ubuntu 18.04.4 LTS и так же в Docker nginx:latest

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


From shilov на extmail.info  Thu Apr 16 08:11:01 2020
From: shilov на extmail.info (Shilov)
Date: Thu, 16 Apr 2020 11:11:01 +0300
Subject: =?UTF-8?B?0J/QvtC00LTQtdGA0LbQutCwINCy0LjQtNC10L7RgdGC0YDQuNC80LjQvdCz0LAg?=
 =?UTF-8?B?0L/QviDQv9GA0L7RgtC+0LrQvtC70YMgUlRTUA==?=
In-Reply-To: <1a8b7a6c2e839443624e00133b7181a1.NginxMailingListRussian@forum.nginx.org>
References: <1a8b7a6c2e839443624e00133b7181a1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200416111101.c0091052fc765592f3099123@extmail.info>

Привет всем!

Скажите, можно ли на основе Nginx организовать видостриминг с IP-видеокамеры, раздающего видеопоток по протоколу RTSP?
И что для этого нужно? :)

-- 
Shilov <shilov на extmail.info>

From nginx-forum на forum.nginx.org  Thu Apr 16 09:08:20 2020
From: nginx-forum на forum.nginx.org (BugBuster)
Date: Thu, 16 Apr 2020 05:08:20 -0400
Subject: =?UTF-8?B?0JrQsNC6INC90LDRgdGC0YDQvtC40YLRjCDRgNC+0YPQvNC40L3QsyDRgSDQv9C+?=
 =?UTF-8?B?0LzQvtGJ0YzRjiByb290Pw==?=
Message-ID: <cf096c2469d248456dcd66baca3ffe8a.NginxMailingListRussian@forum.nginx.org>

Я хочу подставлять переменную в `root` из URL, примерно так:

server { 
listen 80; 
index index.php index.html; 
server_name ~^localhost/(?<project>)/.+$; 
root /var/www/$project/public; 
... 
} 

Идея заключается в том, чтобы настроить роутинг в соответствии с
директориями в корне:

1) "/var/www/project-one/public/index.php" 
2) "/var/www/project-two/public/index.php" 

Таким образом при таких запросах должны отдаваться файлы в соответствующих
директориях проектов:

"http://localhost/project-one/" ->> "/var/www/project-one/public/" 

"http://localhost/project-two/" ->> "/var/www/project-two/public/" 

Можно ли это сделать без использования alias?

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


From xeioex на nginx.com  Thu Apr 16 12:40:17 2020
From: xeioex на nginx.com (Dmitry Volyntsev)
Date: Thu, 16 Apr 2020 15:40:17 +0300
Subject: =?UTF-8?B?UmU6IE5KUyAtINCd0LXQv9GA0LDQstC40LvRjNC90L7QtSDRh9GC0LXQvdC40LUg?=
 =?UTF-8?B?0YTQsNC50LvQsA==?=
In-Reply-To: <1a8b7a6c2e839443624e00133b7181a1.NginxMailingListRussian@forum.nginx.org>
References: <1a8b7a6c2e839443624e00133b7181a1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <469A04B5-31B1-4226-9F69-BBC06EE4CE31@nginx.com>



> On 16 Apr 2020, at 00:41, edc <nginx-forum на forum.nginx.org> wrote:
> 
> Возникла необходимость читать счётчики с сетевых интерфейсов. Метрика
> доступна в файле /sys/class/net/eth0/statistics/rx_bytes 
> NJS возвращает текущее значение и вдобавок к метрике мусор. Похоже весь файл
> читается блоком в 4K. Если тот-же код выполнить в ноде - результат
> корректен.  Правильное ли это поведение njs?
> 
> Пример кода -  test.js
> 
> var fs = require('fs')
> var file = fs.readFileSync('/sys/class/net/eth0/statistics/rx_bytes')
> var file = fs.writeFileSync('filecopy.txt', file)
> 
> Проверка:
> 
> stat /sys/class/net/wlp61s0/statistics/rx_bytes
> 
> File: /sys/class/net/wlp61s0/statistics/rx_bytes
> Size: 4096            Blocks: 0          IO Block: 4096   regular file
> 
> njs  test.js
> stat filecopy.txt 
> 
> File: filecopy.txt
> Size: 4096            Blocks: 8          IO Block: 4096   regular file
> 
> node test.js
> stat filecopy.txt 
> 
> File: filecopy.txt
> Size: 10              Blocks: 8          IO Block: 4096   regular file
> 
> Версии:
> njs -v
> 0.3.9
> 
> node -v
> v8.10.0
> 
> Проверял на Ubuntu 18.04.4 LTS и так же в Docker nginx:latest
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287667,287667#msg-287667


Могу подтвердить проблему, исправим в ближайших релизах. 
njs сейчас доверяет размеру файла полученного через fstat(), который составляет 4096.

В качество workaround могу предложить следующее

: var fs = require(‘fs’)
: var file = fs.readFileSync('/sys/class/net/eth0/statistics/rx_bytes’)
: var rx_bytes = Number(file.slice(0, file.indexOf(‘\n’)));



> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From constantine на mellodesign.ru  Thu Apr 16 20:53:55 2020
From: constantine на mellodesign.ru (=?utf-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=)
Date: Fri, 17 Apr 2020 00:53:55 +0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvdCw0YHRgtGA0L7QuNGC0Ywg0YDQvtGD0LzQuNC90LMg0YEg?=
 =?UTF-8?B?0L/QvtC80L7RidGM0Y4gcm9vdD8=?=
In-Reply-To: <cf096c2469d248456dcd66baca3ffe8a.NginxMailingListRussian@forum.nginx.org>
References: <cf096c2469d248456dcd66baca3ffe8a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <3BAC6EE9-8525-4C48-91F7-B0D3965FEED3@mellodesign.ru>

Здравствуйте!
То, что вы хотите сделать, проще делается через location. Примерно так:

server_name localhost;

location ~ ^/(?<project>)/$ {
    root /var/www/$project/public;
    try_files ...
}

П.С. Пример не проверял

> 16 апр. 2020 г., в 13:08, BugBuster <nginx-forum на forum.nginx.org> написал(а):
> 
> Я хочу подставлять переменную в `root` из URL, примерно так:
> 
> server { 
> listen 80; 
> index index.php index.html; 
> server_name ~^localhost/(?<project>)/.+$; 
> root /var/www/$project/public; 
> ... 
> } 
> 
> Идея заключается в том, чтобы настроить роутинг в соответствии с
> директориями в корне:
> 
> 1) "/var/www/project-one/public/index.php" 
> 2) "/var/www/project-two/public/index.php" 
> 
> Таким образом при таких запросах должны отдаваться файлы в соответствующих
> директориях проектов:
> 
> "http://localhost/project-one/" ->> "/var/www/project-one/public/" 
> 
> "http://localhost/project-two/" ->> "/var/www/project-two/public/" 
> 
> Можно ли это сделать без использования alias?
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287679,287679#msg-287679
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From constantine на mellodesign.ru  Thu Apr 16 20:57:22 2020
From: constantine на mellodesign.ru (=?utf-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=)
Date: Fri, 17 Apr 2020 00:57:22 +0400
Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LrQsCDQstC40LTQtdC+0YHRgtGA0LjQvNC40L0=?=
 =?UTF-8?B?0LPQsCDQv9C+INC/0YDQvtGC0L7QutC+0LvRgyBSVFNQ?=
In-Reply-To: <20200416111101.c0091052fc765592f3099123@extmail.info>
References: <1a8b7a6c2e839443624e00133b7181a1.NginxMailingListRussian@forum.nginx.org>
 <20200416111101.c0091052fc765592f3099123@extmail.info>
Message-ID: <97B09313-2B69-4FEC-8CB3-1110B06CC759@mellodesign.ru>

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

Организовать можно. Проблема в том, что сама IP-камера как правило не способна держать много клиентов. Поэтому простое проксирование делу не поможет, нужно чтобы с камеры поток куда-то сохранялся, а nginx уже его будет раздавать. То есть нужен какой-то кеш, а его способы организации уже разные. Протокол, если мне память не изменяет, роли не особо играет в данном случае.

> 16 апр. 2020 г., в 12:11, Shilov <shilov на extmail.info> написал(а):
> 
> Привет всем!
> 
> Скажите, можно ли на основе Nginx организовать видостриминг с IP-видеокамеры, раздающего видеопоток по протоколу RTSP?
> И что для этого нужно? :)
> 
> -- 
> Shilov <shilov на extmail.info>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From shilov на extmail.info  Fri Apr 17 01:57:30 2020
From: shilov на extmail.info (Shilov)
Date: Fri, 17 Apr 2020 04:57:30 +0300
Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LrQsCDQstC40LTQtdC+0YHRgtGA0LjQvNC40L0=?=
 =?UTF-8?B?0LPQsCDQv9C+INC/0YDQvtGC0L7QutC+0LvRgyBSVFNQ?=
In-Reply-To: <97B09313-2B69-4FEC-8CB3-1110B06CC759@mellodesign.ru>
References: <1a8b7a6c2e839443624e00133b7181a1.NginxMailingListRussian@forum.nginx.org>
 <20200416111101.c0091052fc765592f3099123@extmail.info>
 <97B09313-2B69-4FEC-8CB3-1110B06CC759@mellodesign.ru>
Message-ID: <20200417045730.5737fbb91569b5b34810e560@extmail.info>

Спасибо! 
А если клиентов как раз немного?
Причем видеостриминг им нужен не постоянно, а кратковременно - глянул на минутку, и отключился.


On Fri, 17 Apr 2020 00:57:22 +0400
Константин Ткаченко <constantine на mellodesign.ru> wrote:

> Здравствуйте!
> 
> Организовать можно. Проблема в том, что сама IP-камера как правило не способна держать много клиентов. Поэтому простое проксирование делу не поможет, нужно чтобы с камеры поток куда-то сохранялся, а nginx уже его будет раздавать. То есть нужен какой-то кеш, а его способы организации уже разные. Протокол, если мне память не изменяет, роли не особо играет в данном случае.
> 
> > 16 апр. 2020 г., в 12:11, Shilov <shilov на extmail.info> написал(а):
> > 
> > Привет всем!
> > 
> > Скажите, можно ли на основе Nginx организовать видостриминг с IP-видеокамеры, раздающего видеопоток по протоколу RTSP?
> > И что для этого нужно? :)
> > 
> > -- 
> > Shilov <shilov на extmail.info>
> > _______________________________________________
> > 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

-- 
Shilov <shilov на extmail.info>

From nginx-forum на forum.nginx.org  Fri Apr 17 04:54:39 2020
From: nginx-forum на forum.nginx.org (edc)
Date: Fri, 17 Apr 2020 00:54:39 -0400
Subject: =?UTF-8?B?UmU6IE5KUyAtINCd0LXQv9GA0LDQstC40LvRjNC90L7QtSDRh9GC0LXQvdC40LUg?=
 =?UTF-8?B?0YTQsNC50LvQsA==?=
In-Reply-To: <469A04B5-31B1-4226-9F69-BBC06EE4CE31@nginx.com>
References: <469A04B5-31B1-4226-9F69-BBC06EE4CE31@nginx.com>
Message-ID: <b316edee91a95d6d916511167caa18e0.NginxMailingListRussian@forum.nginx.org>

Спасибо за workaround! И будем ждать bugfix!

E.

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


From nginx-forum на forum.nginx.org  Fri Apr 17 10:08:24 2020
From: nginx-forum на forum.nginx.org (BugBuster)
Date: Fri, 17 Apr 2020 06:08:24 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvdCw0YHRgtGA0L7QuNGC0Ywg0YDQvtGD0LzQuNC90LMg0YEg?=
 =?UTF-8?B?0L/QvtC80L7RidGM0Y4gcm9vdD8=?=
In-Reply-To: <3BAC6EE9-8525-4C48-91F7-B0D3965FEED3@mellodesign.ru>
References: <3BAC6EE9-8525-4C48-91F7-B0D3965FEED3@mellodesign.ru>
Message-ID: <1165787b6ce1b7ef858d1b263d705e1d.NginxMailingListRussian@forum.nginx.org>

К сожалению, root тут не подходит, так как конечный URL будет не корректным:
/var/www/$project/public/$project

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


From maxim на nginx.com  Fri Apr 17 10:13:31 2020
From: maxim на nginx.com (Maxim Konovalov)
Date: Fri, 17 Apr 2020 13:13:31 +0300
Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LrQsCDQstC40LTQtdC+0YHRgtGA0LjQvNC40L0=?=
 =?UTF-8?B?0LPQsCDQv9C+INC/0YDQvtGC0L7QutC+0LvRgyBSVFNQ?=
In-Reply-To: <20200417045730.5737fbb91569b5b34810e560@extmail.info>
References: <1a8b7a6c2e839443624e00133b7181a1.NginxMailingListRussian@forum.nginx.org>
 <20200416111101.c0091052fc765592f3099123@extmail.info>
 <97B09313-2B69-4FEC-8CB3-1110B06CC759@mellodesign.ru>
 <20200417045730.5737fbb91569b5b34810e560@extmail.info>
Message-ID: <f9e7a388-1581-5422-d88f-9e9b69969c48@nginx.com>

Добрый день.

Подозреваю, речь идет о DIY системе видеонаблюдения?

Я такое сделал так: при помощи ffmpeg по rtsp поток снимается с
камеры/камеры и публикуется на nginx+rtmp.  В сторону клиентов hls &
jwplayer.

On 17.04.2020 04:57, Shilov wrote:
> Спасибо! 
> А если клиентов как раз немного?
> Причем видеостриминг им нужен не постоянно, а кратковременно - глянул на минутку, и отключился.
> 
> 
> On Fri, 17 Apr 2020 00:57:22 +0400
> Константин Ткаченко <constantine на mellodesign.ru> wrote:
> 
>> Здравствуйте!
>>
>> Организовать можно. Проблема в том, что сама IP-камера как правило не способна держать много клиентов. Поэтому простое проксирование делу не поможет, нужно чтобы с камеры поток куда-то сохранялся, а nginx уже его будет раздавать. То есть нужен какой-то кеш, а его способы организации уже разные. Протокол, если мне память не изменяет, роли не особо играет в данном случае.
>>
>>> 16 апр. 2020 г., в 12:11, Shilov <shilov на extmail.info> написал(а):
>>>
>>> Привет всем!
>>>
>>> Скажите, можно ли на основе Nginx организовать видостриминг с IP-видеокамеры, раздающего видеопоток по протоколу RTSP?
>>> И что для этого нужно? :)
>>>
>>> -- 
>>> Shilov <shilov на extmail.info>
>>> _______________________________________________
>>> 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
> 


-- 
Maxim Konovalov

From constantine на mellodesign.ru  Fri Apr 17 22:04:10 2020
From: constantine на mellodesign.ru (=?utf-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=)
Date: Sat, 18 Apr 2020 02:04:10 +0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvdCw0YHRgtGA0L7QuNGC0Ywg0YDQvtGD0LzQuNC90LMg0YEg?=
 =?UTF-8?B?0L/QvtC80L7RidGM0Y4gcm9vdD8=?=
In-Reply-To: <1165787b6ce1b7ef858d1b263d705e1d.NginxMailingListRussian@forum.nginx.org>
References: <3BAC6EE9-8525-4C48-91F7-B0D3965FEED3@mellodesign.ru>
 <1165787b6ce1b7ef858d1b263d705e1d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <EB691D8C-E2D2-4418-8544-E32B40AEE93C@mellodesign.ru>

Тогда опишите подробней задачу, так как сейчас я вижу уже другие условия.

> 17 апр. 2020 г., в 14:08, BugBuster <nginx-forum на forum.nginx.org> написал(а):
> 
> К сожалению, root тут не подходит, так как конечный URL будет не корректным:
> /var/www/$project/public/$project
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287679,287695#msg-287695
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From constantine на mellodesign.ru  Fri Apr 17 22:06:24 2020
From: constantine на mellodesign.ru (=?utf-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=)
Date: Sat, 18 Apr 2020 02:06:24 +0400
Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LrQsCDQstC40LTQtdC+0YHRgtGA0LjQvNC40L0=?=
 =?UTF-8?B?0LPQsCDQv9C+INC/0YDQvtGC0L7QutC+0LvRgyBSVFNQ?=
In-Reply-To: <20200417045730.5737fbb91569b5b34810e560@extmail.info>
References: <1a8b7a6c2e839443624e00133b7181a1.NginxMailingListRussian@forum.nginx.org>
 <20200416111101.c0091052fc765592f3099123@extmail.info>
 <97B09313-2B69-4FEC-8CB3-1110B06CC759@mellodesign.ru>
 <20200417045730.5737fbb91569b5b34810e560@extmail.info>
Message-ID: <3103D472-5C7A-49DB-AA68-EA157B26FEEE@mellodesign.ru>

Все камеры с которыми я работал, вели себя очень плохо, это конечно не значит, что и вас будет такая ситуация, но я бы рекомендовал сделать как предложил Максим:

> Я такое сделал так: при помощи ffmpeg по rtsp поток снимается с
> камеры/камеры и публикуется на nginx+rtmp.  В сторону клиентов hls &
> jwplayer.

> 17 апр. 2020 г., в 5:57, Shilov <shilov на extmail.info> написал(а):
> 
> Спасибо! 
> А если клиентов как раз немного?
> Причем видеостриминг им нужен не постоянно, а кратковременно - глянул на минутку, и отключился.
> 
> 
> On Fri, 17 Apr 2020 00:57:22 +0400
> Константин Ткаченко <constantine на mellodesign.ru> wrote:
> 
>> Здравствуйте!
>> 
>> Организовать можно. Проблема в том, что сама IP-камера как правило не способна держать много клиентов. Поэтому простое проксирование делу не поможет, нужно чтобы с камеры поток куда-то сохранялся, а nginx уже его будет раздавать. То есть нужен какой-то кеш, а его способы организации уже разные. Протокол, если мне память не изменяет, роли не особо играет в данном случае.
>> 
>>> 16 апр. 2020 г., в 12:11, Shilov <shilov на extmail.info> написал(а):
>>> 
>>> Привет всем!
>>> 
>>> Скажите, можно ли на основе Nginx организовать видостриминг с IP-видеокамеры, раздающего видеопоток по протоколу RTSP?
>>> И что для этого нужно? :)
>>> 
>>> -- 
>>> Shilov <shilov на extmail.info>
>>> _______________________________________________
>>> 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
> 
> -- 
> Shilov <shilov на extmail.info>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From rogat1y на gmail.com  Sat Apr 18 17:37:42 2020
From: rogat1y на gmail.com (Maxim K)
Date: Sat, 18 Apr 2020 20:37:42 +0300
Subject: =?UTF-8?B?UmU6INCf0L7QtNC00LXRgNC20LrQsCDQstC40LTQtdC+0YHRgtGA0LjQvNC40L0=?=
 =?UTF-8?B?0LPQsCDQv9C+INC/0YDQvtGC0L7QutC+0LvRgyBSVFNQ?=
In-Reply-To: <3103D472-5C7A-49DB-AA68-EA157B26FEEE@mellodesign.ru>
References: <1a8b7a6c2e839443624e00133b7181a1.NginxMailingListRussian@forum.nginx.org>
 <20200416111101.c0091052fc765592f3099123@extmail.info>
 <97B09313-2B69-4FEC-8CB3-1110B06CC759@mellodesign.ru>
 <20200417045730.5737fbb91569b5b34810e560@extmail.info>
 <3103D472-5C7A-49DB-AA68-EA157B26FEEE@mellodesign.ru>
Message-ID: <CAB-_x2OWRuoMEU7BogfGyz3sp7s=dzfd9vn3McrFDrGT92fw8A@mail.gmail.com>

jwplayer можно заменить на hls.js или clappr.
вместо nginx+rtmp можно использовать shaka packager
https://google.github.io/shaka-packager/html/tutorials/ffmpeg_piping.html -
пакетировать hls или dash(тут задержку меньше можно сделать).
hls можно сразу делать на выходе из ffmpeg, без заморочек с rtmp.
nginx тут только для раздачи плейлистов и чанков по http.
Вариантов много. Всё от задачи зависит. Почему rtsp? Какой софт будет в
качестве клиентов?


сб, 18 апр. 2020 г. в 01:06, Константин Ткаченко <constantine на mellodesign.ru
>:

> Все камеры с которыми я работал, вели себя очень плохо, это конечно не
> значит, что и вас будет такая ситуация, но я бы рекомендовал сделать как
> предложил Максим:
>
> > Я такое сделал так: при помощи ffmpeg по rtsp поток снимается с
> > камеры/камеры и публикуется на nginx+rtmp.  В сторону клиентов hls &
> > jwplayer.
>
> > 17 апр. 2020 г., в 5:57, Shilov <shilov на extmail.info> написал(а):
> >
> > Спасибо!
> > А если клиентов как раз немного?
> > Причем видеостриминг им нужен не постоянно, а кратковременно - глянул на
> минутку, и отключился.
> >
> >
> > On Fri, 17 Apr 2020 00:57:22 +0400
> > Константин Ткаченко <constantine на mellodesign.ru> wrote:
> >
> >> Здравствуйте!
> >>
> >> Организовать можно. Проблема в том, что сама IP-камера как правило не
> способна держать много клиентов. Поэтому простое проксирование делу не
> поможет, нужно чтобы с камеры поток куда-то сохранялся, а nginx уже его
> будет раздавать. То есть нужен какой-то кеш, а его способы организации уже
> разные. Протокол, если мне память не изменяет, роли не особо играет в
> данном случае.
> >>
> >>> 16 апр. 2020 г., в 12:11, Shilov <shilov на extmail.info> написал(а):
> >>>
> >>> Привет всем!
> >>>
> >>> Скажите, можно ли на основе Nginx организовать видостриминг с
> IP-видеокамеры, раздающего видеопоток по протоколу RTSP?
> >>> И что для этого нужно? :)
> >>>
> >>> --
> >>> Shilov <shilov на extmail.info>
> >>> _______________________________________________
> >>> 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
> >
> > --
> > Shilov <shilov на extmail.info>
> > _______________________________________________
> > 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
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200418/247c1ea5/attachment.htm>

From denis на webmaster.spb.ru  Mon Apr 20 02:04:03 2020
From: denis на webmaster.spb.ru (denis на webmaster.spb.ru)
Date: Mon, 20 Apr 2020 05:04:03 +0300
Subject: nginx-ldap-auth
In-Reply-To: <2043571586910309@sas1-2bf44b70450e.qloud-c.yandex.net>
References: <2043571586910309@sas1-2bf44b70450e.qloud-c.yandex.net>
Message-ID: <376041587348162@mail.yandex.ru>

Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200420/cddd682d/attachment.htm>

From pavel2000 на ngs.ru  Mon Apr 20 03:27:25 2020
From: pavel2000 на ngs.ru (Pavel)
Date: Mon, 20 Apr 2020 10:27:25 +0700
Subject: nginx-ldap-auth
In-Reply-To: <376041587348162@mail.yandex.ru>
References: <2043571586910309@sas1-2bf44b70450e.qloud-c.yandex.net>
 <376041587348162@mail.yandex.ru>
Message-ID: <e32608e5-61af-f4e4-a0f7-33b17c71d2b4@ngs.ru>

20.04.2020 9:04, denis на webmaster.spb.ru пишет:
> Я так понимаю, ldap не использует никто, даже разработчики собственный 
> модуль... Если оно официально мертво, может закрыть репу 
> https://github.com/nginxinc/nginx-ldap-auth?
>
Тебе лично приятнее будет, если будет меньше открытого кода?

Мне вот "иногда" очень непонятно, с чего люди решают, что им кто-то 
что-то должен?

Вам нужна техподдержка, а это значит вам туда: 
https://www.nginx.com/contact-sales/

>
> 15.04.2020, 03:30, "denis на webmaster.spb.ru" <denis на webmaster.spb.ru>:
>
>     Добрый день
>     Есть в амазоне кластер, с приватной сетью, вход через OpenVPN,
>     после входа у всех один внутренний айпи.
>     Используем nginx-ldap-auth, но у меня получилось завести его в 2
>     режимах:
>     1) авторизуется 1 человек, и все кто через впн могут работать от
>     его имени (cache включен?)
>     2) Вроде с авторизацией всё хорошо, но на каждый запрос через
>     nginx идёт десяток запросов в AD
>     Можно сделать, чтобы выставлялось что-то более уникальное? Я так
>     понимаю, мне в браузер нужна кука. И хотя есть отдельная опция
>     proxy_set_header X-CookieName "nginxauth"; - я не вижу чтобы она
>     работала как надо. Что-то забыто? Или штатно это не сделать и
>     нужны модули вроде https://github.com/sto/ngx_http_auth_pam_module ?
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200420/9640692e/attachment.htm>

From vl на nginx.com  Mon Apr 20 11:19:29 2020
From: vl на nginx.com (Vladimir Homutov)
Date: Mon, 20 Apr 2020 14:19:29 +0300
Subject: nginx-ldap-auth
In-Reply-To: <2043571586910309@sas1-2bf44b70450e.qloud-c.yandex.net>
References: <2043571586910309@sas1-2bf44b70450e.qloud-c.yandex.net>
Message-ID: <93a73a27-aae4-5b81-bd68-ab7ce470216c@nginx.com>


15.04.2020 03:30, denis на webmaster.spb.ru пишет:
> Добрый день
> Есть в амазоне кластер, с приватной сетью, вход через OpenVPN, после 
> входа у всех один внутренний айпи.
> Используем nginx-ldap-auth, но у меня получилось завести его в 2 режимах:
> 1) авторизуется 1 человек, и все кто через впн могут работать от его 
> имени (cache включен?)
> 2) Вроде с авторизацией всё хорошо, но на каждый запрос через nginx 
> идёт десяток запросов в AD
> Можно сделать, чтобы выставлялось что-то более уникальное? Я так 
> понимаю, мне в браузер нужна кука. И хотя есть отдельная опция 
> proxy_set_header X-CookieName "nginxauth"; - я не вижу чтобы она 
> работала как надо. Что-то забыто? Или штатно это не сделать и нужны 
> модули вроде https://github.com/sto/ngx_http_auth_pam_module ?
>
кука сама не появится, её должен ставить бекенд, смотрите пример в 
backend-sample-app.py.

Если используется кеш, то чтобы правильно различать пользователей, 
естественно, нужен уникальный ключ

и правильно настроенный ключ кеширования.

Касательно множества запросов - смотрите в логи насчёт того, что у вас 
там происходит с AD.



From nginx-forum на forum.nginx.org  Tue Apr 21 11:58:16 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Tue, 21 Apr 2020 07:58:16 -0400
Subject: =?UTF-8?B?0KfRgtC+INCy0YvQsdGA0LDRgtGMIGxvY2F0aW9uINC40LvQuCByZXdyaXRlPw==?=
Message-ID: <d3ee7378e4bacb36479551d60a81b7ea.NginxMailingListRussian@forum.nginx.org>

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

Решил на одном сервере отказаться от Апача и подключить php напрямую к
nginx. Т.к. конфиг Апача довольно таки большой, нашел сервис который
конвертировал его под nginx. Пользоваться конечно без допиливания таким
конфигом нельзя, но вот на что я обратил внимание. Все правила Апача
mod_rewrite'а типа:

RewriteRule ^/test/$ test.php [L]
RewriteRule ^/download/$ download.php [L]

сервис конвертировал в:

location = /test {
  rewrite ^(.*)$ /test.php break;
}

location = /download {
  rewrite ^(.*)$ /download.php break;
}

Подскажите, насколько это правильно? Может лучше использовать такой
вариант?

location  / {
  rewrite ^/test/$ /test.php break;
  rewrite ^download/$ /download.php break;
}


Правил rewrite несколько десятков. Какой вариант более правильный и
быстрый?

Спасибо.

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


From chipitsine на gmail.com  Tue Apr 21 13:44:02 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 21 Apr 2020 18:44:02 +0500
Subject: =?UTF-8?B?UmU6INCn0YLQviDQstGL0LHRgNCw0YLRjCBsb2NhdGlvbiDQuNC70LggcmV3cml0?=
 =?UTF-8?B?ZT8=?=
In-Reply-To: <d3ee7378e4bacb36479551d60a81b7ea.NginxMailingListRussian@forum.nginx.org>
References: <d3ee7378e4bacb36479551d60a81b7ea.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQGKgDf=HLW0J7cGXVhYchMm_K4g4VhP5qF_3JiTM5j5Jw@mail.gmail.com>

как показывает практика, оверхед от php на порядки превышает затраты на
любые реврайты, которые вы сможете придумать.

еще интересная практика может быть try_files

try_files $uri $uri/ /index.php?$args;

типа - смотрим, если файл есть локально - отдаем локально. если нет,
то запускаем php интерпретатор.

но надо иметь в виду побочный эффект, если вас будут сканить на набор
урлов, то всё это попадает в php и может сгенерировать нагрузку


пример с try_files я срисовал с
https://www.nginx.com/resources/wiki/start/topics/recipes/wordpress/


вт, 21 апр. 2020 г. в 16:58, grey <nginx-forum на forum.nginx.org>:

> Приветствую.
>
> Решил на одном сервере отказаться от Апача и подключить php напрямую к
> nginx. Т.к. конфиг Апача довольно таки большой, нашел сервис который
> конвертировал его под nginx. Пользоваться конечно без допиливания таким
> конфигом нельзя, но вот на что я обратил внимание. Все правила Апача
> mod_rewrite'а типа:
>
> RewriteRule ^/test/$ test.php [L]
> RewriteRule ^/download/$ download.php [L]
>
> сервис конвертировал в:
>
> location = /test {
>   rewrite ^(.*)$ /test.php break;
> }
>
> location = /download {
>   rewrite ^(.*)$ /download.php break;
> }
>
> Подскажите, насколько это правильно? Может лучше использовать такой
> вариант?
>
> location  / {
>   rewrite ^/test/$ /test.php break;
>   rewrite ^download/$ /download.php break;
> }
>
>
> Правил rewrite несколько десятков. Какой вариант более правильный и
> быстрый?
>
> Спасибо.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,287729,287729#msg-287729
>
> _______________________________________________
> 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/20200421/76ee2c3b/attachment.htm>

From mdounin на mdounin.ru  Tue Apr 21 14:45:05 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 21 Apr 2020 17:45:05 +0300
Subject: nginx-1.18.0
Message-ID: <20200421144505.GW20357@mdounin.ru>

Изменения в nginx 1.18.0                                          21.04.2020

    *) Стабильная ветка 1.18.x.


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

From nginx-forum на forum.nginx.org  Tue Apr 21 20:47:37 2020
From: nginx-forum на forum.nginx.org (nerkas)
Date: Tue, 21 Apr 2020 16:47:37 -0400
Subject: =?UTF-8?B?0JLRi9Cx0L7RgCB1cHN0cmVhbSBzZXJ2ZXIg0LIg0LfQsNCy0LjRgdC40LzQvtGB?=
 =?UTF-8?B?0YLQuCDQvtGCINGC0LjQv9CwIGNsaXBoZXI=?=
Message-ID: <449929b6ce62c738599905550cf710de.NginxMailingListRussian@forum.nginx.org>

Добрый день,
У nginx есть отличный модуль ngx_stream_ssl_preread_module, позволяющий
информацию из ClientHello.
К сожалению с его помощью нельзя получить Cipher suites, и на основе его
выбрать upstream.
У нас имеется два вебсервера, на которых надо терменировать SSL-трафик, один
из них поддерживает ГОСТ-ое шифрование (TLS_GOSTR341001_WITH_28147_CNT_IMIT
и ему подобные).
Необходимо на основе Client Hello (где этот cipher указан), выбрать
upstream.
Возможно ли это решить с помощью Nginx?
Я нашел вот этот модуль (ngx_stream_js_module), с помощью него можно ли
проверить cipher? Я записать какую-нибудь переменную, на основе которой
потом и выбирать upstream?
Если возможно, то можно ли пример похожей задачи показать? К сожалению, по
этому модулю очень мало информации и примеров.
Заранее спасибо за помощь.

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


From chipitsine на gmail.com  Tue Apr 21 21:30:08 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 22 Apr 2020 02:30:08 +0500
Subject: =?UTF-8?B?UmU6INCS0YvQsdC+0YAgdXBzdHJlYW0gc2VydmVyINCyINC30LDQstC40YHQuNC8?=
 =?UTF-8?B?0L7RgdGC0Lgg0L7RgiDRgtC40L/QsCBjbGlwaGVy?=
In-Reply-To: <449929b6ce62c738599905550cf710de.NginxMailingListRussian@forum.nginx.org>
References: <449929b6ce62c738599905550cf710de.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQFZf3pXTW3diSa2k7NT9qb-NtJ3i-mBCH8gOmAdJcHk6Q@mail.gmail.com>

идея не лишена смысла.

но, насчет шифра, клиент ведь посылает несколько шифров на выбор ?


ср, 22 апр. 2020 г. в 01:47, nerkas <nginx-forum на forum.nginx.org>:

> Добрый день,
> У nginx есть отличный модуль ngx_stream_ssl_preread_module, позволяющий
> информацию из ClientHello.
> К сожалению с его помощью нельзя получить Cipher suites, и на основе его
> выбрать upstream.
> У нас имеется два вебсервера, на которых надо терменировать SSL-трафик,
> один
> из них поддерживает ГОСТ-ое шифрование (TLS_GOSTR341001_WITH_28147_CNT_IMIT
> и ему подобные).
> Необходимо на основе Client Hello (где этот cipher указан), выбрать
> upstream.
> Возможно ли это решить с помощью Nginx?
> Я нашел вот этот модуль (ngx_stream_js_module), с помощью него можно ли
> проверить cipher? Я записать какую-нибудь переменную, на основе которой
> потом и выбирать upstream?
> Если возможно, то можно ли пример похожей задачи показать? К сожалению, по
> этому модулю очень мало информации и примеров.
> Заранее спасибо за помощь.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,287748,287748#msg-287748
>
> _______________________________________________
> 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/20200422/36edc83b/attachment.htm>

From nginx-forum на forum.nginx.org  Wed Apr 22 07:19:15 2020
From: nginx-forum на forum.nginx.org (nerkas)
Date: Wed, 22 Apr 2020 03:19:15 -0400
Subject: =?UTF-8?B?UmU6INCS0YvQsdC+0YAgdXBzdHJlYW0gc2VydmVyINCyINC30LDQstC40YHQuNC8?=
 =?UTF-8?B?0L7RgdGC0Lgg0L7RgiDRgtC40L/QsCBjbGlwaGVy?=
In-Reply-To: <CAFHpkQFZf3pXTW3diSa2k7NT9qb-NtJ3i-mBCH8gOmAdJcHk6Q@mail.gmail.com>
References: <CAFHpkQFZf3pXTW3diSa2k7NT9qb-NtJ3i-mBCH8gOmAdJcHk6Q@mail.gmail.com>
Message-ID: <bc3ce06939cccd18e018c6e3f3fa1209.NginxMailingListRussian@forum.nginx.org>

Илья.
Да, верно. Например, браузер Chromium GOST отправляет аж 22 шифра на выбор
(https://imgur.com/a/YdFmCld).Из них 4 это ГОСТ.
Я думал о варианте, что если какой-нибудь из GOST_ есть, то сразу отправлять
на ГОСТ_ вебсервер, а там где ГОСТ-а нет, слать на другой.

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


From chipitsine на gmail.com  Wed Apr 22 07:39:33 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 22 Apr 2020 12:39:33 +0500
Subject: =?UTF-8?B?UmU6INCS0YvQsdC+0YAgdXBzdHJlYW0gc2VydmVyINCyINC30LDQstC40YHQuNC8?=
 =?UTF-8?B?0L7RgdGC0Lgg0L7RgiDRgtC40L/QsCBjbGlwaGVy?=
In-Reply-To: <bc3ce06939cccd18e018c6e3f3fa1209.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQFZf3pXTW3diSa2k7NT9qb-NtJ3i-mBCH8gOmAdJcHk6Q@mail.gmail.com>
 <bc3ce06939cccd18e018c6e3f3fa1209.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQHNRt1V2KdYTwnbZsnUsBw81VV8d+Ot-T6r1n5eQ=W6kg@mail.gmail.com>

да, на этом можно попробовать собрать map.
но вы понимаете, что речь идет о stream-проксировании, т.е. вы просто tcp
поток отправляете на тот или иной бекенд и терминация SSL будет уже на
бекенде?

ср, 22 апр. 2020 г. в 12:19, nerkas <nginx-forum на forum.nginx.org>:

> Илья.
> Да, верно. Например, браузер Chromium GOST отправляет аж 22 шифра на выбор
> (https://imgur.com/a/YdFmCld).Из них 4 это ГОСТ.
> Я думал о варианте, что если какой-нибудь из GOST_ есть, то сразу
> отправлять
> на ГОСТ_ вебсервер, а там где ГОСТ-а нет, слать на другой.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,287748,287755#msg-287755
>
> _______________________________________________
> 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/20200422/b8b9b8fe/attachment.htm>

From bgx на protva.ru  Wed Apr 22 07:50:49 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Wed, 22 Apr 2020 10:50:49 +0300
Subject: =?UTF-8?B?UmU6INCS0YvQsdC+0YAgdXBzdHJlYW0gc2VydmVyINCyINC30LDQstC40YHQuNC8?=
 =?UTF-8?B?0L7RgdGC0Lgg0L7RgiDRgtC40L/QsCBjbGlwaGVy?=
In-Reply-To: <CAFHpkQHNRt1V2KdYTwnbZsnUsBw81VV8d+Ot-T6r1n5eQ=W6kg@mail.gmail.com>
References: <CAFHpkQFZf3pXTW3diSa2k7NT9qb-NtJ3i-mBCH8gOmAdJcHk6Q@mail.gmail.com>
 <bc3ce06939cccd18e018c6e3f3fa1209.NginxMailingListRussian@forum.nginx.org>
 <CAFHpkQHNRt1V2KdYTwnbZsnUsBw81VV8d+Ot-T6r1n5eQ=W6kg@mail.gmail.com>
Message-ID: <20200422075049.GC17004@sie.protva.ru>

On Wed, Apr 22, 2020 at 12:39:33PM +0500, Илья Шипицин wrote:
>    но вы понимаете, что речь идет о stream-проксировании, т.е. вы просто tcp
>    поток отправляете на тот или иной бекенд и терминация SSL будет уже на
>    бекенде?

 Nginx это не софтовый L4-роутер: чтобы разобрать ClientHello
 и обработать ciphersuites ему нужно терминировать SSL.
-- 
 Eugene Berdnikov

From chipitsine на gmail.com  Wed Apr 22 07:55:02 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 22 Apr 2020 12:55:02 +0500
Subject: =?UTF-8?B?UmU6INCS0YvQsdC+0YAgdXBzdHJlYW0gc2VydmVyINCyINC30LDQstC40YHQuNC8?=
 =?UTF-8?B?0L7RgdGC0Lgg0L7RgiDRgtC40L/QsCBjbGlwaGVy?=
In-Reply-To: <20200422075049.GC17004@sie.protva.ru>
References: <CAFHpkQFZf3pXTW3diSa2k7NT9qb-NtJ3i-mBCH8gOmAdJcHk6Q@mail.gmail.com>
 <bc3ce06939cccd18e018c6e3f3fa1209.NginxMailingListRussian@forum.nginx.org>
 <CAFHpkQHNRt1V2KdYTwnbZsnUsBw81VV8d+Ot-T6r1n5eQ=W6kg@mail.gmail.com>
 <20200422075049.GC17004@sie.protva.ru>
Message-ID: <CAFHpkQGCy1Sr9ORDez7vTCzThNmeahaX-X4hiT2jJNFO-SD9yA@mail.gmail.com>

ср, 22 апр. 2020 г. в 12:51, Evgeniy Berdnikov <bgx на protva.ru>:

> On Wed, Apr 22, 2020 at 12:39:33PM +0500, Илья Шипицин wrote:
> >    но вы понимаете, что речь идет о stream-проксировании, т.е. вы просто
> tcp
> >    поток отправляете на тот или иной бекенд и терминация SSL будет уже на
> >    бекенде?
>
>  Nginx это не софтовый L4-роутер: чтобы разобрать ClientHello
>  и обработать ciphersuites ему нужно терминировать SSL.
>

есть технология, в haproxy называется SNI based routing, когда из
SSL-хендшейков извлекается SNI (если он нешифрованный), и далее стрим без
терминации роутится.
в nginx это делается на ngx_stream_ssl_preread


в SSL только пейлод шифрованный. сигнализация вся открытая и доступна без
терминации


> --
>  Eugene Berdnikov
> _______________________________________________
> 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/20200422/fbd7335c/attachment.htm>

From bgx на protva.ru  Wed Apr 22 08:20:52 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Wed, 22 Apr 2020 11:20:52 +0300
Subject: =?UTF-8?B?UmU6INCS0YvQsdC+0YAgdXBzdHJlYW0gc2VydmVyINCyINC30LDQstC40YHQuNC8?=
 =?UTF-8?B?0L7RgdGC0Lgg0L7RgiDRgtC40L/QsCBjbGlwaGVy?=
In-Reply-To: <CAFHpkQGCy1Sr9ORDez7vTCzThNmeahaX-X4hiT2jJNFO-SD9yA@mail.gmail.com>
References: <CAFHpkQFZf3pXTW3diSa2k7NT9qb-NtJ3i-mBCH8gOmAdJcHk6Q@mail.gmail.com>
 <bc3ce06939cccd18e018c6e3f3fa1209.NginxMailingListRussian@forum.nginx.org>
 <CAFHpkQHNRt1V2KdYTwnbZsnUsBw81VV8d+Ot-T6r1n5eQ=W6kg@mail.gmail.com>
 <20200422075049.GC17004@sie.protva.ru>
 <CAFHpkQGCy1Sr9ORDez7vTCzThNmeahaX-X4hiT2jJNFO-SD9yA@mail.gmail.com>
Message-ID: <20200422082052.GD17004@sie.protva.ru>

On Wed, Apr 22, 2020 at 12:55:02PM +0500, Илья Шипицин wrote:
>    ср, 22 апр. 2020 г. в 12:51, Evgeniy Berdnikov <[1]bgx на protva.ru>:
> 
>      On Wed, Apr 22, 2020 at 12:39:33PM +0500, Илья Шипицин wrote:
>      >    но вы понимаете, что речь идет о stream-проксировании, т.е. вы
>      просто tcp
>      >    поток отправляете на тот или иной бекенд и терминация SSL будет уже
>      на
>      >    бекенде?
> 
>       Nginx это не софтовый L4-роутер: чтобы разобрать ClientHello
>       и обработать ciphersuites ему нужно терминировать SSL.
> 
>    есть технология, в haproxy называется SNI based routing, когда из
>    SSL-хендшейков извлекается SNI (если он нешифрованный), и далее стрим без
>    терминации роутится.
>    в nginx это делается на ngx_stream_ssl_preread

 Да, не заметил, нужный модуль есть. Только функционала для выбора шифра
 не хватает. Значит, этот модуль и нужно слегка попатчить.
-- 
 Eugene Berdnikov

From chipitsine на gmail.com  Wed Apr 22 08:42:45 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 22 Apr 2020 13:42:45 +0500
Subject: =?UTF-8?B?UmU6INCS0YvQsdC+0YAgdXBzdHJlYW0gc2VydmVyINCyINC30LDQstC40YHQuNC8?=
 =?UTF-8?B?0L7RgdGC0Lgg0L7RgiDRgtC40L/QsCBjbGlwaGVy?=
In-Reply-To: <20200422082052.GD17004@sie.protva.ru>
References: <CAFHpkQFZf3pXTW3diSa2k7NT9qb-NtJ3i-mBCH8gOmAdJcHk6Q@mail.gmail.com>
 <bc3ce06939cccd18e018c6e3f3fa1209.NginxMailingListRussian@forum.nginx.org>
 <CAFHpkQHNRt1V2KdYTwnbZsnUsBw81VV8d+Ot-T6r1n5eQ=W6kg@mail.gmail.com>
 <20200422075049.GC17004@sie.protva.ru>
 <CAFHpkQGCy1Sr9ORDez7vTCzThNmeahaX-X4hiT2jJNFO-SD9yA@mail.gmail.com>
 <20200422082052.GD17004@sie.protva.ru>
Message-ID: <CAFHpkQFyRHv6NQdYoyGP1PTqONGbqZ=gKV4j=A_NyO15mHb_vg@mail.gmail.com>

ср, 22 апр. 2020 г. в 13:21, Evgeniy Berdnikov <bgx на protva.ru>:

> On Wed, Apr 22, 2020 at 12:55:02PM +0500, Илья Шипицин wrote:
> >    ср, 22 апр. 2020 г. в 12:51, Evgeniy Berdnikov <[1]bgx на protva.ru>:
> >
> >      On Wed, Apr 22, 2020 at 12:39:33PM +0500, Илья Шипицин wrote:
> >      >    но вы понимаете, что речь идет о stream-проксировании, т.е. вы
> >      просто tcp
> >      >    поток отправляете на тот или иной бекенд и терминация SSL
> будет уже
> >      на
> >      >    бекенде?
> >
> >       Nginx это не софтовый L4-роутер: чтобы разобрать ClientHello
> >       и обработать ciphersuites ему нужно терминировать SSL.
> >
> >    есть технология, в haproxy называется SNI based routing, когда из
> >    SSL-хендшейков извлекается SNI (если он нешифрованный), и далее стрим
> без
> >    терминации роутится.
> >    в nginx это делается на ngx_stream_ssl_preread
>
>  Да, не заметил, нужный модуль есть. Только функционала для выбора шифра
>  не хватает. Значит, этот модуль и нужно слегка попатчить.
>


вы про встроенные переменные
https://nginx.org/ru/docs/stream/ngx_stream_ssl_preread_module.html#variables

?


да, сьютов среди них нет

в качестве альтернативы можно попробовать
https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/
я не пробовал на шифрсьютах, но, возможно, что в haproxy сьюты доступны в
переменных


> --
>  Eugene Berdnikov
> _______________________________________________
> 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/20200422/5c9d6f64/attachment-0001.htm>

From slw на zxy.spb.ru  Wed Apr 22 13:31:02 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Wed, 22 Apr 2020 16:31:02 +0300
Subject: =?UTF-8?B?0L/QtdGA0LXQvNC10L3QvdGL0LUgJDE=?=
Message-ID: <20200422133102.GQ8012@zxy.spb.ru>

А это нормально что переменные $1..$N не являются локальными для
регэкспа?

Т.е. если например у нас есть rewrite и там что-то захватывается, а в
результате используется еще и результат map с регэкспом, то $1 будет
браться из map.
Что-то мне кажется это не логично.

From mdounin на mdounin.ru  Wed Apr 22 14:39:23 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 22 Apr 2020 17:39:23 +0300
Subject: =?UTF-8?B?UmU6INC/0LXRgNC10LzQtdC90L3Ri9C1ICQx?=
In-Reply-To: <20200422133102.GQ8012@zxy.spb.ru>
References: <20200422133102.GQ8012@zxy.spb.ru>
Message-ID: <20200422143923.GY20357@mdounin.ru>

Hello!

On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:

> А это нормально что переменные $1..$N не являются локальными для
> регэкспа?
> 
> Т.е. если например у нас есть rewrite и там что-то захватывается, а в
> результате используется еще и результат map с регэкспом, то $1 будет
> браться из map.
> Что-то мне кажется это не логично.

Это следствие того, что regexp и использование $1..$N могут быть 
разнесены, например, в конструкциях вида (цитата из 
http://nginx.org/r/if):

    if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
        set $id $1;
    }

Для rewrite'а это, конечно, не нормально, надо править.  Про это 
даже есть тикет:

https://trac.nginx.org/nginx/ticket/564

Patches are welcome.

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

From slw на zxy.spb.ru  Wed Apr 22 15:15:07 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Wed, 22 Apr 2020 18:15:07 +0300
Subject: =?UTF-8?B?UmU6INC/0LXRgNC10LzQtdC90L3Ri9C1ICQx?=
In-Reply-To: <20200422143923.GY20357@mdounin.ru>
References: <20200422133102.GQ8012@zxy.spb.ru>
 <20200422143923.GY20357@mdounin.ru>
Message-ID: <20200422151507.GR8012@zxy.spb.ru>

On Wed, Apr 22, 2020 at 05:39:23PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
> 
> > А это нормально что переменные $1..$N не являются локальными для
> > регэкспа?
> > 
> > Т.е. если например у нас есть rewrite и там что-то захватывается, а в
> > результате используется еще и результат map с регэкспом, то $1 будет
> > браться из map.
> > Что-то мне кажется это не логично.
> 
> Это следствие того, что regexp и использование $1..$N могут быть 
> разнесены, например, в конструкциях вида (цитата из 
> http://nginx.org/r/if):
> 
>     if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
>         set $id $1;
>     }
> 
> Для rewrite'а это, конечно, не нормально, надо править.  Про это 
> даже есть тикет:

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

> https://trac.nginx.org/nginx/ticket/564
> 
> Patches are welcome.

6 лет...

From mdounin на mdounin.ru  Wed Apr 22 15:59:21 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 22 Apr 2020 18:59:21 +0300
Subject: =?UTF-8?B?UmU6INC/0LXRgNC10LzQtdC90L3Ri9C1ICQx?=
In-Reply-To: <20200422151507.GR8012@zxy.spb.ru>
References: <20200422133102.GQ8012@zxy.spb.ru>
 <20200422143923.GY20357@mdounin.ru>
 <20200422151507.GR8012@zxy.spb.ru>
Message-ID: <20200422155921.GA20357@mdounin.ru>

Hello!

On Wed, Apr 22, 2020 at 06:15:07PM +0300, Slawa Olhovchenkov wrote:

> On Wed, Apr 22, 2020 at 05:39:23PM +0300, Maxim Dounin wrote:
> 
> > Hello!
> > 
> > On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
> > 
> > > А это нормально что переменные $1..$N не являются локальными для
> > > регэкспа?
> > > 
> > > Т.е. если например у нас есть rewrite и там что-то захватывается, а в
> > > результате используется еще и результат map с регэкспом, то $1 будет
> > > браться из map.
> > > Что-то мне кажется это не логично.
> > 
> > Это следствие того, что regexp и использование $1..$N могут быть 
> > разнесены, например, в конструкциях вида (цитата из 
> > http://nginx.org/r/if):
> > 
> >     if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
> >         set $id $1;
> >     }
> > 
> > Для rewrite'а это, конечно, не нормально, надо править.  Про это 
> > даже есть тикет:
> 
> не для rewrite, а для map.
> вроде как логично ожидать, что map срабатывает выдавая указанную
> переменную без каких-либо дополнительных побочных эффектов.

Ну да, одно из возможных решений - отучить регулярные выражения в 
map'е трогать $1..$N.  С другой стороны - конфигурации вида

    map $uri $foo {
        ~(.+) $1;
    }

тоже никто не отменял.

> > https://trac.nginx.org/nginx/ticket/564
> > 
> > Patches are welcome.
> 
> 6 лет...

Да, за 6 лет никто не сподобился даже попытаться прислать патч.  
Что как бы позволяет предложить, что - не жмёт.

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

From slw на zxy.spb.ru  Wed Apr 22 16:14:05 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Wed, 22 Apr 2020 19:14:05 +0300
Subject: =?UTF-8?B?UmU6INC/0LXRgNC10LzQtdC90L3Ri9C1ICQx?=
In-Reply-To: <20200422155921.GA20357@mdounin.ru>
References: <20200422133102.GQ8012@zxy.spb.ru>
 <20200422143923.GY20357@mdounin.ru>
 <20200422151507.GR8012@zxy.spb.ru>
 <20200422155921.GA20357@mdounin.ru>
Message-ID: <20200422161405.GS8012@zxy.spb.ru>

On Wed, Apr 22, 2020 at 06:59:21PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Wed, Apr 22, 2020 at 06:15:07PM +0300, Slawa Olhovchenkov wrote:
> 
> > On Wed, Apr 22, 2020 at 05:39:23PM +0300, Maxim Dounin wrote:
> > 
> > > Hello!
> > > 
> > > On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
> > > 
> > > > А это нормально что переменные $1..$N не являются локальными для
> > > > регэкспа?
> > > > 
> > > > Т.е. если например у нас есть rewrite и там что-то захватывается, а в
> > > > результате используется еще и результат map с регэкспом, то $1 будет
> > > > браться из map.
> > > > Что-то мне кажется это не логично.
> > > 
> > > Это следствие того, что regexp и использование $1..$N могут быть 
> > > разнесены, например, в конструкциях вида (цитата из 
> > > http://nginx.org/r/if):
> > > 
> > >     if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
> > >         set $id $1;
> > >     }
> > > 
> > > Для rewrite'а это, конечно, не нормально, надо править.  Про это 
> > > даже есть тикет:
> > 
> > не для rewrite, а для map.
> > вроде как логично ожидать, что map срабатывает выдавая указанную
> > переменную без каких-либо дополнительных побочных эффектов.
> 
> Ну да, одно из возможных решений - отучить регулярные выражения в 
> map'е трогать $1..$N.  С другой стороны - конфигурации вида
> 
>     map $uri $foo {
>         ~(.+) $1;
>     }
> 
> тоже никто не отменял.

не понимаю возражения.
я как раз о том, что внури map $1..$N локальные и не портят $1..$N в
других местах. очевидно же, что вот этот $1 _вне_ map никому не нужен.
$foo сформировался и никому ничего больше от этого map не требуется.

> > > https://trac.nginx.org/nginx/ticket/564
> > > 
> > > Patches are welcome.
> > 
> > 6 лет...
> 
> Да, за 6 лет никто не сподобился даже попытаться прислать патч.  
> Что как бы позволяет предложить, что - не жмёт.

или никто не может разобраться.

From slw на zxy.spb.ru  Wed Apr 22 16:35:55 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Wed, 22 Apr 2020 19:35:55 +0300
Subject: =?UTF-8?Q?proxy=5Fstore_=D0=B8_ranges?=
Message-ID: <20200422163555.GT8012@zxy.spb.ru>

А что происходит если у нас есть proxy_store а исходный запрос -- с
ranges?
Скачиваем и сохраняем все, отдаем кусок?
Скачиваем и сохраняем кусок а потом глючим?

From chipitsine на gmail.com  Wed Apr 22 16:58:29 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 22 Apr 2020 21:58:29 +0500
Subject: =?UTF-8?B?UmU6INC/0LXRgNC10LzQtdC90L3Ri9C1ICQx?=
In-Reply-To: <20200422161405.GS8012@zxy.spb.ru>
References: <20200422133102.GQ8012@zxy.spb.ru>
 <20200422143923.GY20357@mdounin.ru>
 <20200422151507.GR8012@zxy.spb.ru> <20200422155921.GA20357@mdounin.ru>
 <20200422161405.GS8012@zxy.spb.ru>
Message-ID: <CAFHpkQHsKyzfSf5uEkYC4tg_g6W8D_mfTbuxzaNajhgsNXn38Q@mail.gmail.com>

ср, 22 апр. 2020 г. в 21:14, Slawa Olhovchenkov <slw на zxy.spb.ru>:

> On Wed, Apr 22, 2020 at 06:59:21PM +0300, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Wed, Apr 22, 2020 at 06:15:07PM +0300, Slawa Olhovchenkov wrote:
> >
> > > On Wed, Apr 22, 2020 at 05:39:23PM +0300, Maxim Dounin wrote:
> > >
> > > > Hello!
> > > >
> > > > On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
> > > >
> > > > > А это нормально что переменные $1..$N не являются локальными для
> > > > > регэкспа?
> > > > >
> > > > > Т.е. если например у нас есть rewrite и там что-то захватывается,
> а в
> > > > > результате используется еще и результат map с регэкспом, то $1
> будет
> > > > > браться из map.
> > > > > Что-то мне кажется это не логично.
> > > >
> > > > Это следствие того, что regexp и использование $1..$N могут быть
> > > > разнесены, например, в конструкциях вида (цитата из
> > > > http://nginx.org/r/if):
> > > >
> > > >     if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
> > > >         set $id $1;
> > > >     }
> > > >
> > > > Для rewrite'а это, конечно, не нормально, надо править.  Про это
> > > > даже есть тикет:
> > >
> > > не для rewrite, а для map.
> > > вроде как логично ожидать, что map срабатывает выдавая указанную
> > > переменную без каких-либо дополнительных побочных эффектов.
> >
> > Ну да, одно из возможных решений - отучить регулярные выражения в
> > map'е трогать $1..$N.  С другой стороны - конфигурации вида
> >
> >     map $uri $foo {
> >         ~(.+) $1;
> >     }
> >
> > тоже никто не отменял.
>
> не понимаю возражения.
> я как раз о том, что внури map $1..$N локальные и не портят $1..$N в
> других местах. очевидно же, что вот этот $1 _вне_ map никому не нужен.
> $foo сформировался и никому ничего больше от этого map не требуется.
>
> > > > https://trac.nginx.org/nginx/ticket/564
> > > >
> > > > Patches are welcome.
> > >
> > > 6 лет...
> >
> > Да, за 6 лет никто не сподобился даже попытаться прислать патч.
> > Что как бы позволяет предложить, что - не жмёт.
>
> или никто не может разобраться.
>

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



> _______________________________________________
> 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/20200422/4fe655d6/attachment-0001.htm>

From mdounin на mdounin.ru  Wed Apr 22 21:03:16 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 23 Apr 2020 00:03:16 +0300
Subject: =?UTF-8?B?UmU6INC/0LXRgNC10LzQtdC90L3Ri9C1ICQx?=
In-Reply-To: <20200422161405.GS8012@zxy.spb.ru>
References: <20200422133102.GQ8012@zxy.spb.ru>
 <20200422143923.GY20357@mdounin.ru>
 <20200422151507.GR8012@zxy.spb.ru>
 <20200422155921.GA20357@mdounin.ru>
 <20200422161405.GS8012@zxy.spb.ru>
Message-ID: <20200422210316.GC20357@mdounin.ru>

Hello!

On Wed, Apr 22, 2020 at 07:14:05PM +0300, Slawa Olhovchenkov wrote:

> On Wed, Apr 22, 2020 at 06:59:21PM +0300, Maxim Dounin wrote:
> 
> > Hello!
> > 
> > On Wed, Apr 22, 2020 at 06:15:07PM +0300, Slawa Olhovchenkov wrote:
> > 
> > > On Wed, Apr 22, 2020 at 05:39:23PM +0300, Maxim Dounin wrote:
> > > 
> > > > Hello!
> > > > 
> > > > On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
> > > > 
> > > > > А это нормально что переменные $1..$N не являются локальными для
> > > > > регэкспа?
> > > > > 
> > > > > Т.е. если например у нас есть rewrite и там что-то захватывается, а в
> > > > > результате используется еще и результат map с регэкспом, то $1 будет
> > > > > браться из map.
> > > > > Что-то мне кажется это не логично.
> > > > 
> > > > Это следствие того, что regexp и использование $1..$N могут быть 
> > > > разнесены, например, в конструкциях вида (цитата из 
> > > > http://nginx.org/r/if):
> > > > 
> > > >     if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
> > > >         set $id $1;
> > > >     }
> > > > 
> > > > Для rewrite'а это, конечно, не нормально, надо править.  Про это 
> > > > даже есть тикет:
> > > 
> > > не для rewrite, а для map.
> > > вроде как логично ожидать, что map срабатывает выдавая указанную
> > > переменную без каких-либо дополнительных побочных эффектов.
> > 
> > Ну да, одно из возможных решений - отучить регулярные выражения в 
> > map'е трогать $1..$N.  С другой стороны - конфигурации вида
> > 
> >     map $uri $foo {
> >         ~(.+) $1;
> >     }
> > 
> > тоже никто не отменял.
> 
> не понимаю возражения.
> я как раз о том, что внури map $1..$N локальные и не портят $1..$N в
> других местах. очевидно же, что вот этот $1 _вне_ map никому не нужен.
> $foo сформировался и никому ничего больше от этого map не требуется.

Тут есть два нюанса:

1. Механизм формирования $1..$N - общий, и если map не трогает 
$1..$N - то конструкция выше работать не будет.  А делать так, 
чтобы $1..$N использовали результат выполнения конкретного 
регулярного выражения, а не просто последнего - логично как раз в 
рамках rewrite'а, где это конкретное регулярное выражение 
очевидно.  (Ну то есть в рамках map'а следом тоже встанет вопрос, 
когда в правой части будет $bar$1, где $bar - ещё один map с 
регулярным выражением.  Но это, очевидно, надо будет решать так 
же.)

2. Вообще говоря, побочные эффекты от регулярных выражений в map'е 
быть должны, те же именованные captures - вполне логично 
использовать и много кто использует на практике.  Использовать 
побочные эффекты в виде $1..$N - с моей точки зрения странно, но 
теоретически и это вполне может быть.

> > > > https://trac.nginx.org/nginx/ticket/564
> > > > 
> > > > Patches are welcome.
> > > 
> > > 6 лет...
> > 
> > Да, за 6 лет никто не сподобился даже попытаться прислать патч.  
> > Что как бы позволяет предложить, что - не жмёт.
> 
> или никто не может разобраться.

Это не "или", это именно что "не жмёт".  Затраты на попытаться 
разобраться - превышают количество проблем, которые создаёт 
текущее поведение.

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

From slw на zxy.spb.ru  Wed Apr 22 21:35:25 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Thu, 23 Apr 2020 00:35:25 +0300
Subject: =?UTF-8?B?UmU6INC/0LXRgNC10LzQtdC90L3Ri9C1ICQx?=
In-Reply-To: <20200422210316.GC20357@mdounin.ru>
References: <20200422133102.GQ8012@zxy.spb.ru>
 <20200422143923.GY20357@mdounin.ru>
 <20200422151507.GR8012@zxy.spb.ru>
 <20200422155921.GA20357@mdounin.ru>
 <20200422161405.GS8012@zxy.spb.ru>
 <20200422210316.GC20357@mdounin.ru>
Message-ID: <20200422213525.GU8012@zxy.spb.ru>

On Thu, Apr 23, 2020 at 12:03:16AM +0300, Maxim Dounin wrote:

> > > Ну да, одно из возможных решений - отучить регулярные выражения в 
> > > map'е трогать $1..$N.  С другой стороны - конфигурации вида
> > > 
> > >     map $uri $foo {
> > >         ~(.+) $1;
> > >     }
> > > 
> > > тоже никто не отменял.
> > 
> > не понимаю возражения.
> > я как раз о том, что внури map $1..$N локальные и не портят $1..$N в
> > других местах. очевидно же, что вот этот $1 _вне_ map никому не нужен.
> > $foo сформировался и никому ничего больше от этого map не требуется.
> 
> Тут есть два нюанса:
> 
> 1. Механизм формирования $1..$N - общий, и если map не трогает 
> $1..$N - то конструкция выше работать не будет.  А делать так, 
> чтобы $1..$N использовали результат выполнения конкретного 
> регулярного выражения, а не просто последнего - логично как раз в 
> рамках rewrite'а, где это конкретное регулярное выражение 
> очевидно.  (Ну то есть в рамках map'а следом тоже встанет вопрос, 
> когда в правой части будет $bar$1, где $bar - ещё один map с 
> регулярным выражением.  Но это, очевидно, надо будет решать так 
> же.)
> 
> 2. Вообще говоря, побочные эффекты от регулярных выражений в map'е 
> быть должны, те же именованные captures - вполне логично 
> использовать и много кто использует на практике.  Использовать 
> побочные эффекты в виде $1..$N - с моей точки зрения странно, но 
> теоретически и это вполне может быть.

я понимаю откуда взялось.
что не отменяет гемороя.

> > > > > https://trac.nginx.org/nginx/ticket/564
> > > > > 
> > > > > Patches are welcome.
> > > > 
> > > > 6 лет...
> > > 
> > > Да, за 6 лет никто не сподобился даже попытаться прислать патч.  
> > > Что как бы позволяет предложить, что - не жмёт.
> > 
> > или никто не может разобраться.
> 
> Это не "или", это именно что "не жмёт".  Затраты на попытаться 
> разобраться - превышают количество проблем, которые создаёт 
> текущее поведение.

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

From mdounin на mdounin.ru  Wed Apr 22 22:09:52 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 23 Apr 2020 01:09:52 +0300
Subject: =?UTF-8?Q?Re=3A_proxy=5Fstore_=D0=B8_ranges?=
In-Reply-To: <20200422163555.GT8012@zxy.spb.ru>
References: <20200422163555.GT8012@zxy.spb.ru>
Message-ID: <20200422220952.GD20357@mdounin.ru>

Hello!

On Wed, Apr 22, 2020 at 07:35:55PM +0300, Slawa Olhovchenkov wrote:

> А что происходит если у нас есть proxy_store а исходный запрос -- с
> ranges?
> Скачиваем и сохраняем все, отдаем кусок?
> Скачиваем и сохраняем кусок а потом глючим?

Директива proxy_store не предполагает собственной логики кроме 
собственно сохранения ответов.  При это сохраняются только ответы 
с кодом 200.  Соответственно если бекенд возвращает 206 (Partial 
content), то ответ сохранён не будет.

Если нужно, чтобы ответ всегда сохранялся - заголовок Range можно 
убрать из запроса на бекенд с помощью директивы proxy_set_header.  
Если при этом хочется ещё и вернуть клиенту ответ с учётом 
запрошенных диапазонов, то в простых случаях это можно сделать, 
включив директиву proxy_force_ranges.

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

From ngnx8810773a83 на avksrv.org  Wed Apr 22 23:00:27 2020
From: ngnx8810773a83 на avksrv.org (Alexey)
Date: Thu, 23 Apr 2020 02:00:27 +0300
Subject: =?UTF-8?B?UmU6INC/0LXRgNC10LzQtdC90L3Ri9C1ICQx?=
In-Reply-To: <20200422213525.GU8012@zxy.spb.ru>
References: <20200422133102.GQ8012@zxy.spb.ru>
 <20200422143923.GY20357@mdounin.ru> <20200422151507.GR8012@zxy.spb.ru>
 <20200422155921.GA20357@mdounin.ru> <20200422161405.GS8012@zxy.spb.ru>
 <20200422210316.GC20357@mdounin.ru> <20200422213525.GU8012@zxy.spb.ru>
Message-ID: <622df972-3cd6-13c1-9ed7-839d6d375011@avksrv.org>

День добрый.

23.04.2020 0:35, Slawa Olhovchenkov пишет:
> On Thu, Apr 23, 2020 at 12:03:16AM +0300, Maxim Dounin wrote:
>
>>>> Ну да, одно из возможных решений - отучить регулярные выражения в
>>>> map'е трогать $1..$N.  С другой стороны - конфигурации вида
>>>>
>>>>      map $uri $foo {
>>>>          ~(.+) $1;
>>>>      }
>>>>
>>>> тоже никто не отменял.
>>> не понимаю возражения.
>>> я как раз о том, что внури map $1..$N локальные и не портят $1..$N в
>>> других местах. очевидно же, что вот этот $1 _вне_ map никому не нужен.
>>> $foo сформировался и никому ничего больше от этого map не требуется.
>> Тут есть два нюанса:
>>
>> 1. Механизм формирования $1..$N - общий, и если map не трогает
>> $1..$N - то конструкция выше работать не будет.  А делать так,
>> чтобы $1..$N использовали результат выполнения конкретного
>> регулярного выражения, а не просто последнего - логично как раз в
>> рамках rewrite'а, где это конкретное регулярное выражение
>> очевидно.  (Ну то есть в рамках map'а следом тоже встанет вопрос,
>> когда в правой части будет $bar$1, где $bar - ещё один map с
>> регулярным выражением.  Но это, очевидно, надо будет решать так
>> же.)
>>
>> 2. Вообще говоря, побочные эффекты от регулярных выражений в map'е
>> быть должны, те же именованные captures - вполне логично
>> использовать и много кто использует на практике.  Использовать
>> побочные эффекты в виде $1..$N - с моей точки зрения странно, но
>> теоретически и это вполне может быть.
> я понимаю откуда взялось.
> что не отменяет гемороя.
>
>>>>>> https://trac.nginx.org/nginx/ticket/564
>>>>>>
>>>>>> Patches are welcome.
>>>>> 6 лет...
>>>> Да, за 6 лет никто не сподобился даже попытаться прислать патч.
>>>> Что как бы позволяет предложить, что - не жмёт.
>>> или никто не может разобраться.
>> Это не "или", это именно что "не жмёт".  Затраты на попытаться
>> разобраться - превышают количество проблем, которые создаёт
>> текущее поведение.
> ну хоть бы в документацию большими буквами.
> я не получил большого гемороя только из-за того что в процессе у меня
> и так полный дебаг был включен по другому поводу и я сразу увидел
> такой фифект.


А что, кроме лени, мешает не пользоваться $1$2$3 вообще, а использовать

1. поименованные переменные (?<uniqvar>...)

$uniqvar

2. везде, где переменные не нужны или не использовать скобки, а если не 
возможно или не удобно, использовать  отказ от создания переменной (?:...) ?

и тогда точно будем знать что


map $... {

   ~^start(?<mapvar>)end$  '1';

}


location /(?<locvar>.+)/$ {

   rewrite ^(?:.+)$ /$mapvar/$locvar/? break;

приведет к тому, что хочется.


нет ?

/А



From slw на zxy.spb.ru  Thu Apr 23 09:23:16 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Thu, 23 Apr 2020 12:23:16 +0300
Subject: =?UTF-8?Q?Re=3A_proxy=5Fstore_=D0=B8_ranges?=
In-Reply-To: <20200422220952.GD20357@mdounin.ru>
References: <20200422163555.GT8012@zxy.spb.ru>
 <20200422220952.GD20357@mdounin.ru>
Message-ID: <20200423092316.GV8012@zxy.spb.ru>

On Thu, Apr 23, 2020 at 01:09:52AM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Wed, Apr 22, 2020 at 07:35:55PM +0300, Slawa Olhovchenkov wrote:
> 
> > А что происходит если у нас есть proxy_store а исходный запрос -- с
> > ranges?
> > Скачиваем и сохраняем все, отдаем кусок?
> > Скачиваем и сохраняем кусок а потом глючим?
> 
> Директива proxy_store не предполагает собственной логики кроме 
> собственно сохранения ответов.  При это сохраняются только ответы 
> с кодом 200.  Соответственно если бекенд возвращает 206 (Partial 
> content), то ответ сохранён не будет.
> 
> Если нужно, чтобы ответ всегда сохранялся - заголовок Range можно 
> убрать из запроса на бекенд с помощью директивы proxy_set_header.  
> Если при этом хочется ещё и вернуть клиенту ответ с учётом 
> запрошенных диапазонов, то в простых случаях это можно сделать, 
> включив директиву proxy_force_ranges.

а когда клиент -- это на самом деле модуль который сделал сабреквест
-- это относится к простым случаям?

From mdounin на mdounin.ru  Thu Apr 23 12:17:38 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 23 Apr 2020 15:17:38 +0300
Subject: =?UTF-8?Q?Re=3A_proxy=5Fstore_=D0=B8_ranges?=
In-Reply-To: <20200423092316.GV8012@zxy.spb.ru>
References: <20200422163555.GT8012@zxy.spb.ru>
 <20200422220952.GD20357@mdounin.ru>
 <20200423092316.GV8012@zxy.spb.ru>
Message-ID: <20200423121738.GE20357@mdounin.ru>

Hello!

On Thu, Apr 23, 2020 at 12:23:16PM +0300, Slawa Olhovchenkov wrote:

> On Thu, Apr 23, 2020 at 01:09:52AM +0300, Maxim Dounin wrote:
> 
> > Hello!
> > 
> > On Wed, Apr 22, 2020 at 07:35:55PM +0300, Slawa Olhovchenkov wrote:
> > 
> > > А что происходит если у нас есть proxy_store а исходный запрос -- с
> > > ranges?
> > > Скачиваем и сохраняем все, отдаем кусок?
> > > Скачиваем и сохраняем кусок а потом глючим?
> > 
> > Директива proxy_store не предполагает собственной логики кроме 
> > собственно сохранения ответов.  При это сохраняются только ответы 
> > с кодом 200.  Соответственно если бекенд возвращает 206 (Partial 
> > content), то ответ сохранён не будет.
> > 
> > Если нужно, чтобы ответ всегда сохранялся - заголовок Range можно 
> > убрать из запроса на бекенд с помощью директивы proxy_set_header.  
> > Если при этом хочется ещё и вернуть клиенту ответ с учётом 
> > запрошенных диапазонов, то в простых случаях это можно сделать, 
> > включив директиву proxy_force_ranges.
> 
> а когда клиент -- это на самом деле модуль который сделал сабреквест
> -- это относится к простым случаям?

В подзапросах range'ей в общем случае не бывает вообще.

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

From slw на zxy.spb.ru  Thu Apr 23 12:36:59 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Thu, 23 Apr 2020 15:36:59 +0300
Subject: =?UTF-8?Q?Re=3A_proxy=5Fstore_=D0=B8_ranges?=
In-Reply-To: <20200423121738.GE20357@mdounin.ru>
References: <20200422163555.GT8012@zxy.spb.ru>
 <20200422220952.GD20357@mdounin.ru>
 <20200423092316.GV8012@zxy.spb.ru>
 <20200423121738.GE20357@mdounin.ru>
Message-ID: <20200423123659.GW8012@zxy.spb.ru>

On Thu, Apr 23, 2020 at 03:17:38PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Thu, Apr 23, 2020 at 12:23:16PM +0300, Slawa Olhovchenkov wrote:
> 
> > On Thu, Apr 23, 2020 at 01:09:52AM +0300, Maxim Dounin wrote:
> > 
> > > Hello!
> > > 
> > > On Wed, Apr 22, 2020 at 07:35:55PM +0300, Slawa Olhovchenkov wrote:
> > > 
> > > > А что происходит если у нас есть proxy_store а исходный запрос -- с
> > > > ranges?
> > > > Скачиваем и сохраняем все, отдаем кусок?
> > > > Скачиваем и сохраняем кусок а потом глючим?
> > > 
> > > Директива proxy_store не предполагает собственной логики кроме 
> > > собственно сохранения ответов.  При это сохраняются только ответы 
> > > с кодом 200.  Соответственно если бекенд возвращает 206 (Partial 
> > > content), то ответ сохранён не будет.
> > > 
> > > Если нужно, чтобы ответ всегда сохранялся - заголовок Range можно 
> > > убрать из запроса на бекенд с помощью директивы proxy_set_header.  
> > > Если при этом хочется ещё и вернуть клиенту ответ с учётом 
> > > запрошенных диапазонов, то в простых случаях это можно сделать, 
> > > включив директиву proxy_force_ranges.
> > 
> > а когда клиент -- это на самом деле модуль который сделал сабреквест
> > -- это относится к простым случаям?
> 
> В подзапросах range'ей в общем случае не бывает вообще.

У меня -- есть.
ок, может это формально не позапрос.
Хотя по дебаг логу -- подзапрос (выборочное цититрование, да).

2020/04/22 18:03:00 [debug] 1352#101435: *14 http finalize request: -4, "/vod/segment-15-f1-v1-a1.ts?" a:0, c:3
2020/04/22 18:03:00 [debug] 1352#101435: *14 http subrequest "/ceph/videos/mp4/360.mp4?"
2020/04/22 18:03:00 [debug] 1352#101435: *14 ngx_child_request_start: completed successfully sr=0000000801886890
2020/04/22 18:03:00 [debug] 1352#101435: *14 ngx_http_vod_handler: done
2020/04/22 18:03:00 [debug] 1352#101435: *14 http posted request: "/ceph/videos/mp4/360.mp4?"
2020/04/22 18:03:00 [debug] 1352#101435: *14 http init upstream, client timer: 0
2020/04/22 18:03:00 [debug] 1352#101435: *14 http proxy header: "Range: bytes=18669214-20031179"

From mdounin на mdounin.ru  Thu Apr 23 13:01:40 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 23 Apr 2020 16:01:40 +0300
Subject: =?UTF-8?Q?Re=3A_proxy=5Fstore_=D0=B8_ranges?=
In-Reply-To: <20200423123659.GW8012@zxy.spb.ru>
References: <20200422163555.GT8012@zxy.spb.ru>
 <20200422220952.GD20357@mdounin.ru>
 <20200423092316.GV8012@zxy.spb.ru>
 <20200423121738.GE20357@mdounin.ru>
 <20200423123659.GW8012@zxy.spb.ru>
Message-ID: <20200423130140.GF20357@mdounin.ru>

Hello!

On Thu, Apr 23, 2020 at 03:36:59PM +0300, Slawa Olhovchenkov wrote:

> On Thu, Apr 23, 2020 at 03:17:38PM +0300, Maxim Dounin wrote:
> 
> > Hello!
> > 
> > On Thu, Apr 23, 2020 at 12:23:16PM +0300, Slawa Olhovchenkov wrote:
> > 
> > > On Thu, Apr 23, 2020 at 01:09:52AM +0300, Maxim Dounin wrote:
> > > 
> > > > Hello!
> > > > 
> > > > On Wed, Apr 22, 2020 at 07:35:55PM +0300, Slawa Olhovchenkov wrote:
> > > > 
> > > > > А что происходит если у нас есть proxy_store а исходный запрос -- с
> > > > > ranges?
> > > > > Скачиваем и сохраняем все, отдаем кусок?
> > > > > Скачиваем и сохраняем кусок а потом глючим?
> > > > 
> > > > Директива proxy_store не предполагает собственной логики кроме 
> > > > собственно сохранения ответов.  При это сохраняются только ответы 
> > > > с кодом 200.  Соответственно если бекенд возвращает 206 (Partial 
> > > > content), то ответ сохранён не будет.
> > > > 
> > > > Если нужно, чтобы ответ всегда сохранялся - заголовок Range можно 
> > > > убрать из запроса на бекенд с помощью директивы proxy_set_header.  
> > > > Если при этом хочется ещё и вернуть клиенту ответ с учётом 
> > > > запрошенных диапазонов, то в простых случаях это можно сделать, 
> > > > включив директиву proxy_force_ranges.
> > > 
> > > а когда клиент -- это на самом деле модуль который сделал сабреквест
> > > -- это относится к простым случаям?
> > 
> > В подзапросах range'ей в общем случае не бывает вообще.
> 
> У меня -- есть.
> ок, может это формально не позапрос.
> Хотя по дебаг логу -- подзапрос (выборочное цититрование, да).

Тут какое дело.  То, что в рамках подзапроса можно отправить на 
бекенд range-запрос, добавив соответствующий заголовк Range - не 
значит, что в подзапросах есть range'и.  Это значит лишь то, что 
ответ на подзапрос доступен как есть, ровно то, что вернул бекенд.  
Что с этим делать - решает тот, кто соответствующие подзапросы 
создавал и обрабатывает.

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

Соответственно возвращаясь к исходному вопросу: если заголовка 
Range в подзапросе на бекенд не будет, то ответ бекенда ожидаемо 
будет полный.  Что с этим будет делать конкретный сторонний модуль - 
вопрос к конкретному стороннему модулю.

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

From slw на zxy.spb.ru  Thu Apr 23 13:14:32 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Thu, 23 Apr 2020 16:14:32 +0300
Subject: =?UTF-8?Q?Re=3A_proxy=5Fstore_=D0=B8_ranges?=
In-Reply-To: <20200423130140.GF20357@mdounin.ru>
References: <20200422163555.GT8012@zxy.spb.ru>
 <20200422220952.GD20357@mdounin.ru>
 <20200423092316.GV8012@zxy.spb.ru>
 <20200423121738.GE20357@mdounin.ru>
 <20200423123659.GW8012@zxy.spb.ru>
 <20200423130140.GF20357@mdounin.ru>
Message-ID: <20200423131432.GX8012@zxy.spb.ru>

On Thu, Apr 23, 2020 at 04:01:40PM +0300, Maxim Dounin wrote:

> > > > а когда клиент -- это на самом деле модуль который сделал сабреквест
> > > > -- это относится к простым случаям?
> > > 
> > > В подзапросах range'ей в общем случае не бывает вообще.
> > 
> > У меня -- есть.
> > ок, может это формально не позапрос.
> > Хотя по дебаг логу -- подзапрос (выборочное цититрование, да).
> 
> Тут какое дело.  То, что в рамках подзапроса можно отправить на 
> бекенд range-запрос, добавив соответствующий заголовк Range - не 
> значит, что в подзапросах есть range'и.  Это значит лишь то, что 
> ответ на подзапрос доступен как есть, ровно то, что вернул бекенд.  
> Что с этим делать - решает тот, кто соответствующие подзапросы 
> создавал и обрабатывает.
> 
> Скажем, в частном случае модуля split - подзапросами запрашиваются 
> куски файла с бекенда, и потом результат склеивается для ответа на 
> запрос клиента, в том числе с учётом запрошенного клиентом 
> диапазона.  Но разбираться с тем, что именно вернулось на 
> конкретные подзапросы - это задача модуля split, который эти 
> подзапросы делал, а не nginx'а.  Сам nginx занимается обработкой 
> range-запросов только в рамках ответа на запросы клиентов.
> 
> Соответственно возвращаясь к исходному вопросу: если заголовка 
> Range в подзапросе на бекенд не будет, то ответ бекенда ожидаемо 
> будет полный.  Что с этим будет делать конкретный сторонний модуль - 
> вопрос к конкретному стороннему модулю.

а, вот так понятно, спасибо.

From nginx-forum на forum.nginx.org  Thu Apr 23 14:33:55 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Thu, 23 Apr 2020 10:33:55 -0400
Subject: =?UTF-8?B?UmU6INCn0YLQviDQstGL0LHRgNCw0YLRjCBsb2NhdGlvbiDQuNC70LggcmV3cml0?=
 =?UTF-8?B?ZT8=?=
In-Reply-To: <d3ee7378e4bacb36479551d60a81b7ea.NginxMailingListRussian@forum.nginx.org>
References: <d3ee7378e4bacb36479551d60a81b7ea.NginxMailingListRussian@forum.nginx.org>
Message-ID: <3fbc4e02f9c1b29df2c01eaafa69081e.NginxMailingListRussian@forum.nginx.org>

Продолжаю попытки подружить nginx с php, но что-то застрял на одном моменте.
В документации ответа не нашел :( У меня php выполняет код, который
находится в файлах php/html. 

Вот сильно порезанный конфиг:

server {
	root /www/site.ru;

	location / {
		rewrite ^/123/qwe/asd.html$ /1.php last;
	}

	location ~ \.(php|html)$ {
		fastcgi_pass   127.0.0.1:9123;
		fastcgi_index  index.php;
		fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
		include        fastcgi_params;
	}
}

Т.к. последний location имеет больший приоритет над первым, то при переходе
по адресу site.ru/123/qwe/asd.html я получаю сообщение "No input file
specified.", т.к. естественно по этому пути такого файла нет.

Подскажите, как настроить nginx, чтобы и правила rewrite c файлами html
работали, и для тех файлов, которые реально существуют nginx запускал их на
выполнение через php?

Сейчас сделал через "костыли", но мне не нравится это решение.

Спасибо.

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


From nginx-forum на forum.nginx.org  Thu Apr 23 14:49:05 2020
From: nginx-forum на forum.nginx.org (Dmytro Lavryk)
Date: Thu, 23 Apr 2020 10:49:05 -0400
Subject: =?UTF-8?B?UmU6INCn0YLQviDQstGL0LHRgNCw0YLRjCBsb2NhdGlvbiDQuNC70LggcmV3cml0?=
 =?UTF-8?B?ZT8=?=
In-Reply-To: <3fbc4e02f9c1b29df2c01eaafa69081e.NginxMailingListRussian@forum.nginx.org>
References: <d3ee7378e4bacb36479551d60a81b7ea.NginxMailingListRussian@forum.nginx.org>
 <3fbc4e02f9c1b29df2c01eaafa69081e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <c4120804e90fb2c59593da8949a79c37.NginxMailingListRussian@forum.nginx.org>

- location / {
rewrite ^/123/qwe/asd.html$ /1.php last;
- }

Т.е. вынести rewrite выше - на уровень server

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


From nginx-forum на forum.nginx.org  Fri Apr 24 08:15:13 2020
From: nginx-forum на forum.nginx.org (Dmytro Lavryk)
Date: Fri, 24 Apr 2020 04:15:13 -0400
Subject: =?UTF-8?B?0J7RgtGK0LXQtNCw0LXRgiDQv9Cw0LzRj9GC0Ywg0Lgg0L3QsNGH0LjQvdCw0LU=?=
 =?UTF-8?B?0YIg0YLQvtGA0LzQvtC30LjRgtGMLiDQn9C+0LzQvtCz0LjRgtC1INC90LA=?=
 =?UTF-8?B?0LnRgtC4INC/0YDQuNGH0LjQvdGDLg==?=
Message-ID: <10be2c8640ff9b9c5922468d7f917b1d.NginxMailingListRussian@forum.nginx.org>

Доброго всем здоровья, в сложившейся обстановке.

Есть nginx c "замороченным конфигом". Используется для проксирования раздачи
видео по секьюрити ссылкам. Уонфиг такой достался, лично мне не везде
понятен. потому... Суть ситуации - потребление памяти процессами nginx все
время растет.. при достижении какого-то пикового значения (~1,2Гб на процесс
/их 16-ть получается/) сильно падает скорость отдачи. при этом свободная
память в ситеме все еще есть. Хотелось бы понять 2 момента:
1. Почему происходит потеря продуктивности?
2. Почему потребление памяти все время растет, а не ограничивается на
каком-то уровне?

-----------------------------
cat /etc/nginx/nginx.conf | grep -v '#'

user  www-data;
worker_processes auto;
worker_rlimit_nofile 1024000;

pid        /var/run/nginx.pid;
events {
  worker_connections    8192;
  worker_aio_requests 16;
  multi_accept on;
  use epoll;
}

thread_pool pool_0 threads=16;
thread_pool pool_1 threads=16;
thread_pool pool_2 threads=16;

http {
  include       /etc/nginx/mime.types;
  default_type  application/octet-stream;

  log_format graylog2_json escape=json '{ "host": "$host", "remote_addr":
"$remote_addr", "ssl_protocol": "$ssl_protocol", "ssl_cipher":
"$ssl_cipher", "body_bytes_sent": "$body_bytes_sent", "status": "$status",
"request": "$request", "request_uri": "$request_uri", "request_method":
"$request_method", "request_scheme": "$scheme", "server_protocol":
"$server_protocol", "http_referer": "$http_referer", "http_version":
"$http_version", "http_user_agent": "$http_user_agent", "request_time":
"$request_time", "upstream_cache_status": "$upstream_cache_status",
"upstream_addr": "$upstream_addr"}';

  map $status $loggable {
    ~^[23]  0;
    default 1;
  }

  access_log syslog:server=graylog.insave.ovh:12201 graylog2_json
if=$loggable;
  error_log syslog:server=graylog.insave.ovh:12302;

  keepalive_timeout     15;
  keepalive_requests 1000;
  client_header_timeout 20;
  client_body_timeout 20;
  reset_timedout_connection on;
  send_timeout 20;

  variables_hash_max_size 2048;
  variables_hash_bucket_size 128;

  sendfile            on;
  tcp_nopush          on;
  tcp_nodelay         on;
  types_hash_max_size 2048;
  server_tokens       off;

  client_max_body_size    128m;
  client_body_buffer_size 128k;

  proxy_cache_path /mnt/disk0 levels=1:2 keys_zone=cache_0:1024m
max_size=1700G inactive=1d use_temp_path=off;
  proxy_cache_path /mnt/disk1 levels=1:2 keys_zone=cache_1:1024m
max_size=1700G inactive=1d use_temp_path=off;
  proxy_cache_path /mnt/disk2 levels=1:2 keys_zone=cache_2:1024m
max_size=1700G inactive=1d use_temp_path=off;

  split_clients $hls_key $disk {
    33.3%    0;
    33.3%    1;
    *        2;
  }

  proxy_connect_timeout       60s;
  proxy_send_timeout          60s;
  proxy_read_timeout          60s;
  proxy_buffer_size           64k;
  proxy_buffers               4 32k;
  proxy_busy_buffers_size     64k;
  proxy_http_version          1.1;
  proxy_max_temp_file_size    4096m;
  proxy_temp_file_write_size  4m;
  proxy_ignore_client_abort   on;

  fastcgi_buffers 16 4k;
  fastcgi_buffer_size 4k;
  fastcgi_connect_timeout 100;
  fastcgi_send_timeout 100;

  gzip          on;
  gzip_proxied  any;
  gzip_types    application/vnd.apple.mpegurl video/f4m application/dash+xml
text/xml application/x-javascript application/javascript text/css;

  brotli        on;
  brotli_comp_level 4;
  brotli_types  application/vnd.apple.mpegurl video/f4m application/dash+xml
text/xml application/x-javascript application/javascript text/css;

  vod_metadata_cache metadata_cache 4096m 30m;
  vod_response_cache response_cache 256m 30m;
  vod_cache_buffer_size 512k;

  open_file_cache max=512000 inactive=5m;
  open_file_cache_valid 2m;
  open_file_cache_min_uses 2;
  open_file_cache_errors on;
  aio on;

  include /etc/nginx/sites-enabled/*.conf;
}
------------------------------------

nginx -v
nginx version: nginx/1.16.1
------------------------------------

nginx -V (я немного отформатировал для удобства)

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_gunzip_module
--with-http_gzip_static_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-http_geoip_module
--add-module=../nginx-vod-module
--add-module=../nginx-secure-token-module
--add-module=../nginx-akamai-token-validate-module
--add-module=../ngx_devel_kit
--add-module=../ngx_brotli
--add-module=../set-misc-nginx-module
--add-module=../ngx_cache_purge
--with-cc-opt='-g -O2 -specs=/usr/share/dpkg/no-pie-compile.specs
-fstack-protector-strong -Wformat -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fPIC'
--with-ld-opt='-specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro
-Wl,-z,now -Wl,--as-needed -pie'
---------------------------

lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

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


From nginx-forum на forum.nginx.org  Sat Apr 25 12:23:30 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Sat, 25 Apr 2020 08:23:30 -0400
Subject: =?UTF-8?B?UmU6INCn0YLQviDQstGL0LHRgNCw0YLRjCBsb2NhdGlvbiDQuNC70LggcmV3cml0?=
 =?UTF-8?B?ZT8=?=
In-Reply-To: <c4120804e90fb2c59593da8949a79c37.NginxMailingListRussian@forum.nginx.org>
References: <d3ee7378e4bacb36479551d60a81b7ea.NginxMailingListRussian@forum.nginx.org>
 <3fbc4e02f9c1b29df2c01eaafa69081e.NginxMailingListRussian@forum.nginx.org>
 <c4120804e90fb2c59593da8949a79c37.NginxMailingListRussian@forum.nginx.org>
Message-ID: <8213ced3bf20ef8d60974ae57a7079f5.NginxMailingListRussian@forum.nginx.org>

А если будет два десятка правил rewrite до секций location, не будет ли это
сильно влиять на производительность? Или опять таки php больше грузит
сервер, чем nginx и можно этим пренебречь?

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


From nginx-forum на forum.nginx.org  Sat Apr 25 15:04:22 2020
From: nginx-forum на forum.nginx.org (BuTbk@)
Date: Sat, 25 Apr 2020 11:04:22 -0400
Subject: nginx + WebDav = MS Office read only
Message-ID: <c4edadb8bd92b5e1af6f71444f8d9ee2.NginxMailingListRussian@forum.nginx.org>

Нашел инструкцию(http://netlab.dhis.org/wiki/ru:software:nginx:webdav),
чтобы виндовый клиент нормально работал с ресурсом. Все работает прекрасно,
за исключением того, что офисные доки открываются только в режиме
чтения(проверил, через IIS все нормально работает). Пробовал добавить
dav_ext_methods LOCK UNLOCK; Но это ничего не изменило.
Гугл ничего толкового не выдал. Может кто сталкивался?

Debian buster
libnginx-mod-http-auth-pam/stable,stable,now 1.14.2-2+deb10u1 amd64
[установлен, автоматически]
libnginx-mod-http-cache-purge/stable,stable,now 1.14.2-2+deb10u1 amd64
[установлен, автоматически]
libnginx-mod-http-dav-ext/stable,stable,now 1.14.2-2+deb10u1 amd64
[установлен, автоматически]
libnginx-mod-http-echo/stable,stable,now 1.14.2-2+deb10u1 amd64 [установлен,
автоматически]
libnginx-mod-http-fancyindex/stable,stable,now 1.14.2-2+deb10u1 amd64
[установлен, автоматически]
libnginx-mod-http-geoip/stable,stable,now 1.14.2-2+deb10u1 amd64
[установлен, автоматически]
libnginx-mod-http-headers-more-filter/stable,stable,now 1.14.2-2+deb10u1
amd64 [установлен, автоматически]
libnginx-mod-http-image-filter/stable,stable,now 1.14.2-2+deb10u1 amd64
[установлен, автоматически]
libnginx-mod-http-lua/stable,stable,now 1.14.2-2+deb10u1 amd64 [установлен,
автоматически]
libnginx-mod-http-ndk/stable,stable,now 1.14.2-2+deb10u1 amd64 [установлен,
автоматически]
libnginx-mod-http-perl/stable,stable,now 1.14.2-2+deb10u1 amd64 [установлен,
автоматически]
libnginx-mod-http-subs-filter/stable,stable,now 1.14.2-2+deb10u1 amd64
[установлен, автоматически]
libnginx-mod-http-uploadprogress/stable,stable,now 1.14.2-2+deb10u1 amd64
[установлен, автоматически]
libnginx-mod-http-upstream-fair/stable,stable,now 1.14.2-2+deb10u1 amd64
[установлен, автоматически]
libnginx-mod-http-xslt-filter/stable,stable,now 1.14.2-2+deb10u1 amd64
[установлен, автоматически]
libnginx-mod-mail/stable,stable,now 1.14.2-2+deb10u1 amd64 [установлен,
автоматически]
libnginx-mod-nchan/stable,stable,now 1.14.2-2+deb10u1 amd64 [установлен,
автоматически]
libnginx-mod-stream/stable,stable,now 1.14.2-2+deb10u1 amd64 [установлен,
автоматически]
nginx-common/stable,stable,now 1.14.2-2+deb10u1 all [установлен,
автоматически]
nginx-extras/stable,stable,now 1.14.2-2+deb10u1 amd64 [установлен]

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


From bgx на protva.ru  Sat Apr 25 15:38:15 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Sat, 25 Apr 2020 18:38:15 +0300
Subject: nginx + WebDav = MS Office read only
In-Reply-To: <c4edadb8bd92b5e1af6f71444f8d9ee2.NginxMailingListRussian@forum.nginx.org>
References: <c4edadb8bd92b5e1af6f71444f8d9ee2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200425153815.GA17004@sie.protva.ru>

On Sat, Apr 25, 2020 at 11:04:22AM -0400, BuTbk@ wrote:
> Нашел инструкцию(http://netlab.dhis.org/wiki/ru:software:nginx:webdav),
> чтобы виндовый клиент нормально работал с ресурсом. Все работает прекрасно,
> за исключением того, что офисные доки открываются только в режиме
> чтения(проверил, через IIS все нормально работает). Пробовал добавить
> dav_ext_methods LOCK UNLOCK; Но это ничего не изменило.
> Гугл ничего толкового не выдал. Может кто сталкивался?

 AFAIK, локов недостаточно для rw, нужна поддержка PROPPATCH, а её
 у nginx-а нет. Точнее, винде это нужно, а davfs2 нет, он работает.
 Так что проксируйте мелкомягких на IIS.
-- 
 Eugene Berdnikov

From mdounin на mdounin.ru  Sat Apr 25 15:58:47 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Sat, 25 Apr 2020 18:58:47 +0300
Subject: =?UTF-8?B?UmU6INCe0YLRitC10LTQsNC10YIg0L/QsNC80Y/RgtGMINC4INC90LDRh9C40L0=?=
 =?UTF-8?B?0LDQtdGCINGC0L7RgNC80L7Qt9C40YLRjC4g0J/QvtC80L7Qs9C40YLQtSA=?=
 =?UTF-8?B?0L3QsNC50YLQuCDQv9GA0LjRh9C40L3Rgy4=?=
In-Reply-To: <10be2c8640ff9b9c5922468d7f917b1d.NginxMailingListRussian@forum.nginx.org>
References: <10be2c8640ff9b9c5922468d7f917b1d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200425155847.GI20357@mdounin.ru>

Hello!

On Fri, Apr 24, 2020 at 04:15:13AM -0400, Dmytro Lavryk wrote:

> Доброго всем здоровья, в сложившейся обстановке.
> 
> Есть nginx c "замороченным конфигом". Используется для проксирования раздачи
> видео по секьюрити ссылкам. Уонфиг такой достался, лично мне не везде
> понятен. потому... Суть ситуации - потребление памяти процессами nginx все
> время растет.. при достижении какого-то пикового значения (~1,2Гб на процесс
> /их 16-ть получается/) сильно падает скорость отдачи. при этом свободная
> память в ситеме все еще есть. Хотелось бы понять 2 момента:
> 1. Почему происходит потеря продуктивности?
> 2. Почему потребление памяти все время растет, а не ограничивается на
> каком-то уровне?

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

>   vod_metadata_cache metadata_cache 4096m 30m;
>   vod_response_cache response_cache 256m 30m;

в конфиге означает ещё до 4 с лишним гигабайт разделяемой памяти.

То есть банальный запуск nginx'а с такой конфигурацией потребует 
более 7 гигабайт памяти.

И при этом, судя по всему, минимум 512 килобайт буферов будет 
расходоваться на соединение ("vod_cache_buffer_size 512k;"), то 
есть до 4 гигабайт на процесс (512k * 8192).  А скорее всего и 
больше, сколько требует тот же brotli - надо разбираться.

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

Что до потери скорости отдачи - то тут надо разбираться в причинах 
по месту, смотреть, во что именно упираемся.  Типичные причины: 
упёрлись в диск, кончилась память (даже если она "в системе всё 
ещё есть" - уменьшение количества свободной памяти в системе 
означает ухудшение эффективности кэширования файлов операционной 
системой, и соответственно рост нагрузки на диск), кончилась сеть, 
кончился процессор.

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

Из совсем простого - выкиньте из конфига open_file_cache, толку от 
него с вероятностью 99.99% нет вообще никакого, а проблем огрести 
можно легко и непринуждённо, особенно при тех настройках что у 
вас: с 512 тысячами открытых файлов на каждый процесс банально OS 
может не справиться без специального тюнинга.

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

From nginx-forum на forum.nginx.org  Sat Apr 25 16:36:54 2020
From: nginx-forum на forum.nginx.org (BuTbk@)
Date: Sat, 25 Apr 2020 12:36:54 -0400
Subject: nginx + WebDav = MS Office read only
In-Reply-To: <20200425153815.GA17004@sie.protva.ru>
References: <20200425153815.GA17004@sie.protva.ru>
Message-ID: <0326d59aa2b38f815071208906f174fe.NginxMailingListRussian@forum.nginx.org>

Может что-то можно тут подправить, чтобы офис открывал файлы в режиме
редактирования? 
if ($request_method = PROPPATCH) { # Unsupported, allways return OK.
	add_header	Content-Type 'text/xml';
	return		207 '<?xml version="1.0"?><a:multistatus
xmlns:a="DAV:"><a:response><a:propstat><a:status>HTTP/1.1 200
OK</a:status></a:propstat></a:response></a:multistatus>';
}

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


From bgx на protva.ru  Sat Apr 25 16:48:06 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Sat, 25 Apr 2020 19:48:06 +0300
Subject: nginx + WebDav = MS Office read only
In-Reply-To: <0326d59aa2b38f815071208906f174fe.NginxMailingListRussian@forum.nginx.org>
References: <20200425153815.GA17004@sie.protva.ru>
 <0326d59aa2b38f815071208906f174fe.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200425164806.GC17004@sie.protva.ru>

On Sat, Apr 25, 2020 at 12:36:54PM -0400, BuTbk@ wrote:
> Может что-то можно тут подправить, чтобы офис открывал файлы в режиме
> редактирования? 
> if ($request_method = PROPPATCH) { # Unsupported, allways return OK.
> 	add_header	Content-Type 'text/xml';
> 	return		207 '<?xml version="1.0"?><a:multistatus
> xmlns:a="DAV:"><a:response><a:propstat><a:status>HTTP/1.1 200
> OK</a:status></a:propstat></a:response></a:multistatus>';
> }

 Конечно, это можно отправить в мусорку... Но в результате выбрасывания
 заглушек из конфигов чуда не произойдёт: внутри nginx не появится код
 обработчика PROPPATCH, если его изначально не было. :)
-- 
 Eugene Berdnikov

From dmitry.goryainov на gmail.com  Sat Apr 25 19:49:04 2020
From: dmitry.goryainov на gmail.com (Dmitry Goryainov)
Date: Sat, 25 Apr 2020 22:49:04 +0300
Subject: =?UTF-8?B?UmU6INCn0YLQviDQstGL0LHRgNCw0YLRjCBsb2NhdGlvbiDQuNC70LggcmV3cml0?=
 =?UTF-8?B?ZT8=?=
In-Reply-To: <8213ced3bf20ef8d60974ae57a7079f5.NginxMailingListRussian@forum.nginx.org>
References: <d3ee7378e4bacb36479551d60a81b7ea.NginxMailingListRussian@forum.nginx.org>
 <3fbc4e02f9c1b29df2c01eaafa69081e.NginxMailingListRussian@forum.nginx.org>
 <c4120804e90fb2c59593da8949a79c37.NginxMailingListRussian@forum.nginx.org>
 <8213ced3bf20ef8d60974ae57a7079f5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAHzBpYURB7Qi8ghCoDhEMhpDrAv39xEtp5_gnFAkU_-y416aig@mail.gmail.com>

Где-то в 2014, если не путаю, Игорь читал доклад на HightLoad о том, что
есть оптимизации nginx и лучше регулярные выражения делать внутри
именованных локейшенов.



On Sat, Apr 25, 2020 at 3:23 PM grey <nginx-forum на forum.nginx.org> wrote:

> А если будет два десятка правил rewrite до секций location, не будет ли это
> сильно влиять на производительность? Или опять таки php больше грузит
> сервер, чем nginx и можно этим пренебречь?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,287729,287809#msg-287809
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



-- 
Dmitry Goryainov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200425/613e5bfd/attachment-0001.htm>

From zend.karabanov на gmail.com  Sat Apr 25 21:26:14 2020
From: zend.karabanov на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCa0LDRgNCw0LHQsNC90L7Qsg==?=)
Date: Sun, 26 Apr 2020 00:26:14 +0300
Subject: =?UTF-8?B?0JTQstCwIElQINCw0LTRgNC10YHQsCDQuCDQvdC10L7QttC40LTQsNC90L3QvtC1?=
 =?UTF-8?B?INC/0L7QstC10LTQtdC90LjQtSBOZ2lueA==?=
Message-ID: <CABF7A-j5azmpDDiunK61=oMHM9j3BKCKYSxFLd1y7gpUc_btyA@mail.gmail.com>

Здравствуйте.
У сервера стало два IP.
Казалось бы достаточно в конфигах заменить listen x.x.x.x:80 на listen *:80
и выполнить systemctl reload nginx.service но нет, во-первых после
перечитывания конфига ничего не происходит, то есть он просто не
перечитывается, всё продолжает работать, как и работало.
Явная остановка и запуск демона приносят плоды и Nginx начинает слушать
0.0.0.0:80, но после этого все сайты перестают работать (Nginx отвечает
404).
Только явное указание двух директив listen с двумя IP и явная
остановка/запуск демона решают проблему, после чего всё начинает работать,
как ожидается.

Что не так с listen *:80, почему так не работает?

-- 
С уважением,
Александр Карабанов
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200426/a353053c/attachment.htm>

From zend.karabanov на gmail.com  Sat Apr 25 21:56:27 2020
From: zend.karabanov на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCa0LDRgNCw0LHQsNC90L7Qsg==?=)
Date: Sun, 26 Apr 2020 00:56:27 +0300
Subject: =?UTF-8?B?UmU6INCU0LLQsCBJUCDQsNC00YDQtdGB0LAg0Lgg0L3QtdC+0LbQuNC00LDQvdC9?=
 =?UTF-8?B?0L7QtSDQv9C+0LLQtdC00LXQvdC40LUgTmdpbng=?=
In-Reply-To: <CABF7A-j5azmpDDiunK61=oMHM9j3BKCKYSxFLd1y7gpUc_btyA@mail.gmail.com>
References: <CABF7A-j5azmpDDiunK61=oMHM9j3BKCKYSxFLd1y7gpUc_btyA@mail.gmail.com>
Message-ID: <CABF7A-iKwHteNPX1GVmZ7Xsh-6Somb5rVO0OPyO-36u_uE14zw@mail.gmail.com>

Дело в том, что у дефолтного сервера был явно указан IP и изменение listen
х.х.х.х:80 на listen *:80 у виртуальных хостов делало его приоритетным и
именно он отвечал 404 на запросы.
Я заменил и в дефолтном сервере listen на listen *:80 после чего всё
заработало.

вс, 26 апр. 2020 г. в 00:26, Александр Карабанов <zend.karabanov на gmail.com>:

> Здравствуйте.
> У сервера стало два IP.
> Казалось бы достаточно в конфигах заменить listen x.x.x.x:80 на listen
> *:80 и выполнить systemctl reload nginx.service но нет, во-первых после
> перечитывания конфига ничего не происходит, то есть он просто не
> перечитывается, всё продолжает работать, как и работало.
> Явная остановка и запуск демона приносят плоды и Nginx начинает слушать
> 0.0.0.0:80, но после этого все сайты перестают работать (Nginx отвечает
> 404).
> Только явное указание двух директив listen с двумя IP и явная
> остановка/запуск демона решают проблему, после чего всё начинает работать,
> как ожидается.
>
> Что не так с listen *:80, почему так не работает?
>
> --
> С уважением,
> Александр Карабанов
>


-- 
С уважением,
Александр Карабанов
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200426/ebd8bdfa/attachment.htm>

From mdounin на mdounin.ru  Sat Apr 25 23:02:27 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Sun, 26 Apr 2020 02:02:27 +0300
Subject: =?UTF-8?B?UmU6INCU0LLQsCBJUCDQsNC00YDQtdGB0LAg0Lgg0L3QtdC+0LbQuNC00LDQvdC9?=
 =?UTF-8?B?0L7QtSDQv9C+0LLQtdC00LXQvdC40LUgTmdpbng=?=
In-Reply-To: <CABF7A-j5azmpDDiunK61=oMHM9j3BKCKYSxFLd1y7gpUc_btyA@mail.gmail.com>
References: <CABF7A-j5azmpDDiunK61=oMHM9j3BKCKYSxFLd1y7gpUc_btyA@mail.gmail.com>
Message-ID: <20200425230227.GJ20357@mdounin.ru>

Hello!

On Sun, Apr 26, 2020 at 12:26:14AM +0300, Александр Карабанов wrote:

> Здравствуйте.
> У сервера стало два IP.
> Казалось бы достаточно в конфигах заменить listen x.x.x.x:80 на listen *:80
> и выполнить systemctl reload nginx.service но нет, во-первых после
> перечитывания конфига ничего не происходит, то есть он просто не
> перечитывается, всё продолжает работать, как и работало.

В логе при этом будет явно означена возникшая при попытке 
переконфигурации ошибка.  Вы, судя по всему, используете Linux, а 
на линуксе "из соображений безопасности" нельзя открыть сокет на 
"*" (AKA 0.0.0.0, AKA INADDR_ANY) и на конкретном IP-адресе на 
одном и том же порту.  В результате изменить конфигурацию с 
"слушали только на одном IP-адресе" и "слушаем на INADDR_ANY" 
невозможно, так как при изменении конфигурации nginx попытается 
открыть оба сокета (один будет открыт в "старой" конфигурации, а 
другой nginx попытается открыть для "новой" - получит ошибку, и 
откатится на старую конфигурацию).

> Явная остановка и запуск демона приносят плоды и Nginx начинает слушать
> 0.0.0.0:80, но после этого все сайты перестают работать (Nginx отвечает
> 404).

А тут проблема проще: если у вас в конфиге встречается и 0.0.0.0 и 
конкретный IP-адрес, то nginx по умолчанию открывает один общий 
listen-сокет на 0.0.0.0 (чтобы и на линуксе тоже работало; 
отдельные сокеты можно явно подребовать с помощью параметра bind), и 
ведёт себя так, как должны вести себя соединения для 
соответствующих разных сокетов: то есть соединения к конкретному 
IP-адресу обрабатываются только там, где указан listen для этого 
конкретного IP-адреса, а остальные соединения - там, где указан 
listen на 0.0.0.0.

> Только явное указание двух директив listen с двумя IP и явная
> остановка/запуск демона решают проблему, после чего всё начинает работать,
> как ожидается.
> 
> Что не так с listen *:80, почему так не работает?

С "listen *:80" всё так, однако:

а) Надо понимать, как работают listen-сокеты.  Использование 
"listen *:80" совместно с "listen <ip>:80" подразумевает вполне 
конкретную логику обработки соединений, приходящих на заданный 
ip-адрес (они будут обрабатываться в тех блоках server, где 
используется "listen <ip>:80") и все другие адреса (они будут 
использоваться там, где используется "listen *:80").

б) На Линуксе при переключениями между конфигурациями, где 
используется "listen *:80" и где он не используется вообще - могут 
возникать сложности, налагаемые особенностями реализации TCP-стека 
конкретной операционной системы (на других операционных системах 
таких проблем нет).  Соответствующие ошибки явно отражаются в логе 
ошибок (как и любые другие ошибки, возникающие при 
переконфигурации, кстати; вообще в лог ошибок полезно заглядывать, 
он не просто так существует).

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

From zend.karabanov на gmail.com  Sun Apr 26 00:20:13 2020
From: zend.karabanov на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCa0LDRgNCw0LHQsNC90L7Qsg==?=)
Date: Sun, 26 Apr 2020 03:20:13 +0300
Subject: =?UTF-8?B?UmU6INCU0LLQsCBJUCDQsNC00YDQtdGB0LAg0Lgg0L3QtdC+0LbQuNC00LDQvdC9?=
 =?UTF-8?B?0L7QtSDQv9C+0LLQtdC00LXQvdC40LUgTmdpbng=?=
In-Reply-To: <20200425230227.GJ20357@mdounin.ru>
References: <CABF7A-j5azmpDDiunK61=oMHM9j3BKCKYSxFLd1y7gpUc_btyA@mail.gmail.com>
 <20200425230227.GJ20357@mdounin.ru>
Message-ID: <CABF7A-iSygcZT2XNX_HZPggM75BtX5UDiX8nYn--MHKJ0kV2tQ@mail.gmail.com>

Спасибо за подробный ответ.
Проблема была в том, что был server {...} в котором был явно указан IP,
когда я для него тоже указал listen *:80 всё заработало, как и ожидается,
собственно так, как вы и описали.

вс, 26 апр. 2020 г. в 02:02, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Sun, Apr 26, 2020 at 12:26:14AM +0300, Александр Карабанов wrote:
>
> > Здравствуйте.
> > У сервера стало два IP.
> > Казалось бы достаточно в конфигах заменить listen x.x.x.x:80 на listen
> *:80
> > и выполнить systemctl reload nginx.service но нет, во-первых после
> > перечитывания конфига ничего не происходит, то есть он просто не
> > перечитывается, всё продолжает работать, как и работало.
>
> В логе при этом будет явно означена возникшая при попытке
> переконфигурации ошибка.  Вы, судя по всему, используете Linux, а
> на линуксе "из соображений безопасности" нельзя открыть сокет на
> "*" (AKA 0.0.0.0, AKA INADDR_ANY) и на конкретном IP-адресе на
> одном и том же порту.  В результате изменить конфигурацию с
> "слушали только на одном IP-адресе" и "слушаем на INADDR_ANY"
> невозможно, так как при изменении конфигурации nginx попытается
> открыть оба сокета (один будет открыт в "старой" конфигурации, а
> другой nginx попытается открыть для "новой" - получит ошибку, и
> откатится на старую конфигурацию).
>
> > Явная остановка и запуск демона приносят плоды и Nginx начинает слушать
> > 0.0.0.0:80, но после этого все сайты перестают работать (Nginx отвечает
> > 404).
>
> А тут проблема проще: если у вас в конфиге встречается и 0.0.0.0 и
> конкретный IP-адрес, то nginx по умолчанию открывает один общий
> listen-сокет на 0.0.0.0 (чтобы и на линуксе тоже работало;
> отдельные сокеты можно явно подребовать с помощью параметра bind), и
> ведёт себя так, как должны вести себя соединения для
> соответствующих разных сокетов: то есть соединения к конкретному
> IP-адресу обрабатываются только там, где указан listen для этого
> конкретного IP-адреса, а остальные соединения - там, где указан
> listen на 0.0.0.0.
>
> > Только явное указание двух директив listen с двумя IP и явная
> > остановка/запуск демона решают проблему, после чего всё начинает
> работать,
> > как ожидается.
> >
> > Что не так с listen *:80, почему так не работает?
>
> С "listen *:80" всё так, однако:
>
> а) Надо понимать, как работают listen-сокеты.  Использование
> "listen *:80" совместно с "listen <ip>:80" подразумевает вполне
> конкретную логику обработки соединений, приходящих на заданный
> ip-адрес (они будут обрабатываться в тех блоках server, где
> используется "listen <ip>:80") и все другие адреса (они будут
> использоваться там, где используется "listen *:80").
>
> б) На Линуксе при переключениями между конфигурациями, где
> используется "listen *:80" и где он не используется вообще - могут
> возникать сложности, налагаемые особенностями реализации TCP-стека
> конкретной операционной системы (на других операционных системах
> таких проблем нет).  Соответствующие ошибки явно отражаются в логе
> ошибок (как и любые другие ошибки, возникающие при
> переконфигурации, кстати; вообще в лог ошибок полезно заглядывать,
> он не просто так существует).
>
> --
> Maxim Dounin
> http://mdounin.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/20200426/bd27e476/attachment-0001.htm>

From nginx-forum на forum.nginx.org  Sun Apr 26 18:24:18 2020
From: nginx-forum на forum.nginx.org (BuTbk@)
Date: Sun, 26 Apr 2020 14:24:18 -0400
Subject: nginx + WebDav = MS Office read only
In-Reply-To: <20200425164806.GC17004@sie.protva.ru>
References: <20200425164806.GC17004@sie.protva.ru>
Message-ID: <6f54adbb708615521d501c59d47c4460.NginxMailingListRussian@forum.nginx.org>

А планируется ли в ближайшем будущем PROPPATCH?

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


From nginx-forum на forum.nginx.org  Mon Apr 27 13:33:08 2020
From: nginx-forum на forum.nginx.org (gz)
Date: Mon, 27 Apr 2020 09:33:08 -0400
Subject: =?UTF-8?B?aHR0cDIgcHVzaCDigJQg0L3QtSDQv9C70LDQvdC40YDRg9C10YLRgdGPINC70Lgg?=
 =?UTF-8?B?0L/QvtC00LTQtdGA0LbQutCwIDxsaW5rIHJlbD0icHJlbG9hZCI+INC/0L4g?=
 =?UTF-8?B?0LDQvdCw0LvQvtCz0LjQuCDRgSDQt9Cw0LPQvtC70L7QstC60L7QvCBMaW5r?=
 =?UTF-8?B?Pw==?=
Message-ID: <a2c8245ccccd516670b6e498eebda8b7.NginxMailingListRussian@forum.nginx.org>

В HTML страницы бэкендом выдаются элементы <link rel="preload"> с указанием
на ресурсы для предзагрузки.
Хотелось бы перейти с предзагрузки на http2_push указанных ресурсов.

Казалось бы, нет проблемы перейти на заголовок Link, который модулем
ngx_http_v2_module при http2_push_preload on будет преобразован в push'и.
Однако, в путях к ресурсам используются SSI-вставки с текущими версиями, а
HTML вместе в SSI-директивами хранится в кэше.
Условно:
<html>
	<head>
		<link rel="preload" href="/css/style.css?<!--#echo var="style_css_version"
default="1"-->" as="style"/>
		…
		<link rel="stylesheet" href="/css/style.css?<!--#echo
var="style_css_version" default="1"-->"/>
		…
	</head>
	<body>
		…
	</body>
</html>

А после работы SSI получаем нужный результат:
<html>
	<head>
		<link rel="preload" href="/css/style.css?123456789" as="style"/>
		…
		<link rel="stylesheet" href="/css/style.css?123456789"/>
		…
	</head>
	<body>
		…
	</body>
</html>

Выходит, поможет либо поддержка SSI в заголовках ответа — чего nginx не
умеет, либо поддержка модулем ngx_http_v2_module преобразования <link
rel="preload"> в http2_push.

Посмотрел, было, в строну njs в надежде что смогу процессить тело ответа
после SSI, выкусывать оттуда <link rel="preload">, преобразовывать их в
Link-заголовки, которые затем будут преобразованы в ngx_http_v2_module в
push'и, но в js_content тело ответа оказалось пустым, а js_filter работает
на уровне stream'а.
Так же попробовал использовать js_set для формирования заголовка Link на
основе <link rel="preload"> в теле, но в этом случае в теле <link
rel="preload"> в теле сохранятся и неясно как поведёт себя браузер при
получении и preload-инструкций и http2_push'а.

Нет ли в планах поддерживать преобразования <link rel="preload"> в
http2_push?

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


From nginx-forum на forum.nginx.org  Mon Apr 27 13:38:23 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Mon, 27 Apr 2020 09:38:23 -0400
Subject: =?UTF-8?B?bmdpbnggKyBwaHAtZnBtID0g0LHQsNCzPw==?=
Message-ID: <9754a97d0e6c332495c80e7d192864c6.NginxMailingListRussian@forum.nginx.org>

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

Прежде чем создавать топик, перепроверил всё несколько раз, но объяснения
такого поведения nginx найти не смог.

Суть проблемы: если из php-скрипта со своего сервера я обращаюсь посредством
curl или fopen к своему же сайту, то получаю ошибку "504 Gateway Time-out".
Если выполнить в консоли сервера "php /www/test.ru/1.php", то скрипт вернет
html-страницу сервера. Если открыть в браузере адрес test.ru/1.php, то сайт
будет какое-то время думать, а по прошествию таймаута вернет "504 Gateway
Time-out" (пока сайт будет думать, в лог будут сыпаться ошибки
2020/04/27 15:02:09 [error] 6540#6968: *960636 connect() failed (10061: No
connection could be made because the target machine actively refused it)
while connecting to upstream, client: 5.34.*.*, server: test.ru, request:
"GET / HTTP/2.0", upstream: "fastcgi://127.0.0.1:9123", host: "test.ru",
referrer: "http://***.ru/"). Если в скрипте заменить адрес сервера test.ru
на любой другой внешний, пусть будет ya.ru, то и в консоли и в браузере все
открывает без ошибок. Из чего я делаю вывод, php тут не при чем, затык
именно в nginx. nginx не самой последней версии - 1.17.3 и обновить пока не
могу, php 7.3.х - тоже самая последняя версия.

Конфиг nginx-а минимальный.

server {
	server_name  test.ru;

	location ~ \.(php|html)$ {
		fastcgi_pass   127.0.0.1:9123;
		fastcgi_index  index.php;
		fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
		include        fastcgi_params;
	}
}

Сам скрипт, который вызывает проблему:

<?php
 	$ch = curl_init();
	curl_setopt($ch, CURLOPT_URL, "https://test.ru/");
    	curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
	curl_setopt($ch, CURLOPT_HEADER, 1);
	curl_setopt($ch, CURLOPT_NOBODY, 0);
	curl_setopt($ch, CURLOPT_FOLLOWLOCATION, TRUE);
	curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
	curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);
	$$contents=curl_exec ($ch);
	curl_close ($ch);

/*
или вариант без curl-а
$handle = fopen("https://test.ru", "rb");
$contents = stream_get_contents($handle);
fclose($handle);
*/

echo $contents;
?>

Может это я где-то туплю, но где понять не могу и почему смена адреса решает
проблему?

Просьба проверить у себя.

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


From ngnx8810773a83 на avksrv.org  Mon Apr 27 14:29:18 2020
From: ngnx8810773a83 на avksrv.org (Alexey)
Date: Mon, 27 Apr 2020 17:29:18 +0300
Subject: =?UTF-8?B?UmU6IG5naW54ICsgcGhwLWZwbSA9INCx0LDQsz8=?=
In-Reply-To: <9754a97d0e6c332495c80e7d192864c6.NginxMailingListRussian@forum.nginx.org>
References: <9754a97d0e6c332495c80e7d192864c6.NginxMailingListRussian@forum.nginx.org>
Message-ID: <96eb9418-b10d-7925-5bce-86003ae7beec@avksrv.org>

27.04.2020 16:38, grey пишет:
> Приветствую всех!
>
> Прежде чем создавать топик, перепроверил всё несколько раз, но объяснения
> такого поведения nginx найти не смог.
>
> Суть проблемы: если из php-скрипта со своего сервера я обращаюсь посредством
> curl или fopen к своему же сайту, то получаю ошибку "504 Gateway Time-out".
> Если выполнить в консоли сервера "php /www/test.ru/1.php", то скрипт вернет
> html-страницу сервера. Если открыть в браузере адрес test.ru/1.php, то сайт
> будет какое-то время думать, а по прошествию таймаута вернет "504 Gateway
> Time-out" (пока сайт будет думать, в лог будут сыпаться ошибки
> 2020/04/27 15:02:09 [error] 6540#6968: *960636 connect() failed (10061: No
> connection could be made because the target machine actively refused it)
> while connecting to upstream, client: 5.34.*.*, server: test.ru, request:
> "GET / HTTP/2.0", upstream: "fastcgi://127.0.0.1:9123", host: "test.ru",
> referrer: "http://***.ru/"). Если в скрипте заменить адрес сервера test.ru
> на любой другой внешний, пусть будет ya.ru, то и в консоли и в браузере все
> открывает без ошибок. Из чего я делаю вывод, php тут не при чем, затык
> именно в nginx. nginx не самой последней версии - 1.17.3 и обновить пока не
> могу, php 7.3.х - тоже самая последняя версия.

А почему в нгинксе, а не в php. сделайте запрос за статичным файлом к 
тому же нгинксу, который отдаётся не  через php.

Воркеров php сколько ? точно >1?

/А

From mdounin на mdounin.ru  Mon Apr 27 14:58:55 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 27 Apr 2020 17:58:55 +0300
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <a2c8245ccccd516670b6e498eebda8b7.NginxMailingListRussian@forum.nginx.org>
References: <a2c8245ccccd516670b6e498eebda8b7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200427145855.GR20357@mdounin.ru>

Hello!

On Mon, Apr 27, 2020 at 09:33:08AM -0400, gz wrote:

> В HTML страницы бэкендом выдаются элементы <link rel="preload"> с указанием
> на ресурсы для предзагрузки.
> Хотелось бы перейти с предзагрузки на http2_push указанных ресурсов.

А вы пробовали тестировать, что вы получите на выходе?  Имеющиеся 
исследования про эффективность HTTP/2 push позволяют предолжить, 
что результат скорее всего будет хуже, чем то, что у вас есть 
сейчас.

[...]

> Нет ли в планах поддерживать преобразования <link rel="preload"> в
> http2_push?

Нет, такого в планах нет.

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

From nginx-forum на forum.nginx.org  Mon Apr 27 15:07:44 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Mon, 27 Apr 2020 11:07:44 -0400
Subject: =?UTF-8?B?UmU6IG5naW54ICsgcGhwLWZwbSA9INCx0LDQsz8=?=
In-Reply-To: <96eb9418-b10d-7925-5bce-86003ae7beec@avksrv.org>
References: <96eb9418-b10d-7925-5bce-86003ae7beec@avksrv.org>
Message-ID: <b3e8d2eb7b9cab4e894575eda819f373.NginxMailingListRussian@forum.nginx.org>

Сгораю от стыда - дело было в количестве воркеров :)

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


From nginx-forum на forum.nginx.org  Mon Apr 27 18:44:26 2020
From: nginx-forum на forum.nginx.org (gz)
Date: Mon, 27 Apr 2020 14:44:26 -0400
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <20200427145855.GR20357@mdounin.ru>
References: <20200427145855.GR20357@mdounin.ru>
Message-ID: <c8d8b4ac2d32709ce33f3729e5276e37.NginxMailingListRussian@forum.nginx.org>

Maxim Dounin Wrote:
-------------------------------------------------------
> > В HTML страницы бэкендом выдаются элементы <link rel="preload"> с
> указанием
> > на ресурсы для предзагрузки.
> > Хотелось бы перейти с предзагрузки на http2_push указанных ресурсов.
> 
> А вы пробовали тестировать, что вы получите на выходе?

Практически не проверял, но здравый смысл подсказывает, что даже в рамках
HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить минимум
один запрос на получение ресурсов, объявленных в <link rel="preload">.

> Имеющиеся исследования про эффективность HTTP/2 push позволяют предолжить,

> что результат скорее всего будет хуже, чем то, что у вас есть 
> сейчас.

Я встречал обратные исследования.
https://dexecure.com/blog/http2-push-vs-http-preload/

Плюс у push шире поддерживается.

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


From mdounin на mdounin.ru  Mon Apr 27 19:15:50 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 27 Apr 2020 22:15:50 +0300
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <c8d8b4ac2d32709ce33f3729e5276e37.NginxMailingListRussian@forum.nginx.org>
References: <20200427145855.GR20357@mdounin.ru>
 <c8d8b4ac2d32709ce33f3729e5276e37.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200427191550.GS20357@mdounin.ru>

Hello!

On Mon, Apr 27, 2020 at 02:44:26PM -0400, gz wrote:

> Maxim Dounin Wrote:
> -------------------------------------------------------
> > > В HTML страницы бэкендом выдаются элементы <link rel="preload"> с
> > указанием
> > > на ресурсы для предзагрузки.
> > > Хотелось бы перейти с предзагрузки на http2_push указанных ресурсов.
> > 
> > А вы пробовали тестировать, что вы получите на выходе?
> 
> Практически не проверял, но здравый смысл подсказывает, что даже в рамках
> HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить минимум
> один запрос на получение ресурсов, объявленных в <link rel="preload">.

Здравый смысл тут подсказывает неправильно.  Поскольку сервер не 
знает, какие ресурсы уже есть у клиента, а каких ещё нет, он шлёт 
push'ы всегда, и тем самым расходует как канал, так и лишние 
ресурсы на сервере.  Соответственно результат будет зависеть от 
того, насколько польза от push'а (сэкономленный 1 rtt при запросе 
дополнительных ресурсов у тех клиентов, у которых этих ресурсов 
нет) больше или меньше тех проблем, которые push добавляет всем 
остальным клиентам.

> > Имеющиеся исследования про эффективность HTTP/2 push позволяют предолжить,
> 
> > что результат скорее всего будет хуже, чем то, что у вас есть 
> > сейчас.
> 
> Я встречал обратные исследования.
> https://dexecure.com/blog/http2-push-vs-http-preload/

По ссылке нет исследований, там только общие соображения.  
Исследования выглядят как-то так:

https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf

> Плюс у push шире поддерживается.

Я бы не был столь категоричен. 

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

From nginx-forum на forum.nginx.org  Mon Apr 27 20:29:44 2020
From: nginx-forum на forum.nginx.org (gz)
Date: Mon, 27 Apr 2020 16:29:44 -0400
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <20200427191550.GS20357@mdounin.ru>
References: <20200427191550.GS20357@mdounin.ru>
Message-ID: <52b8986c257de5e0bfe4e7e9ed5792c8.NginxMailingListRussian@forum.nginx.org>

> > Maxim Dounin Wrote:
> > -------------------------------------------------------
> > > > В HTML страницы бэкендом выдаются элементы <link rel="preload">
> с
> > > указанием
> > > > на ресурсы для предзагрузки.
> > > > Хотелось бы перейти с предзагрузки на http2_push указанных
> ресурсов.
> > > 
> > > А вы пробовали тестировать, что вы получите на выходе?
> > 
> > Практически не проверял, но здравый смысл подсказывает, что даже в
> рамках
> > HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить
> минимум
> > один запрос на получение ресурсов, объявленных в <link
> rel="preload">.
> 
> Здравый смысл тут подсказывает неправильно. Поскольку сервер не 
> знает, какие ресурсы уже есть у клиента, а каких ещё нет, он шлёт 
> push'ы всегда, и тем самым расходует как канал, так и лишние 
> ресурсы на сервере. Соответственно результат будет зависеть от 
> того, насколько польза от push'а (сэкономленный 1 rtt при запросе 
> дополнительных ресурсов у тех клиентов, у которых этих ресурсов 
> нет) больше или меньше тех проблем, которые push добавляет всем 
> остальным клиентам.

Востребованные ресурсы из push-кэша переходят в основной и будут
использованы для следующих страниц.
Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся в
кэше.
В крайнем случае несложно пометить клиента стандартным способом через
cookie.

> > > Имеющиеся исследования про эффективность HTTP/2 push позволяют
> предолжить,
> > 
> > > что результат скорее всего будет хуже, чем то, что у вас есть 
> > > сейчас.
> > 
> > Я встречал обратные исследования.
> > https://dexecure.com/blog/http2-push-vs-http-preload/
> 
> По ссылке нет исследований, там только общие соображения.  
> Исследования выглядят как-то так:
> 
>
https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf

Не совсем понимаю какие выводы делают авторы.

Предлагают работать над приоритезацией (которая и так корректная, и
регулируется preload'ом), использовать экспериментальный QUIC, поддержики
которого толком нет.

> > Плюс у push шире поддерживается.
> 
> Я бы не был столь категоричен. 

Нет никакой категоричности:
https://caniuse.com/#search=rel%20preload — 84%
https://caniuse.com/#feat=http2 — 94%

Не совсем корректное сравнение точно preload vs push, тем не менее.

Я прекрасно понимаю, что push — не панацея, и хотел попробовать на практике
проталкивание критических ресурсов, которые в любом случае приоритетны и
будут загружены для отрисовки.

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


From chipitsine на gmail.com  Mon Apr 27 20:40:41 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 28 Apr 2020 01:40:41 +0500
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <52b8986c257de5e0bfe4e7e9ed5792c8.NginxMailingListRussian@forum.nginx.org>
References: <20200427191550.GS20357@mdounin.ru>
 <52b8986c257de5e0bfe4e7e9ed5792c8.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQFhVJDaPNSTyg-jXOR9j66n+tUT5dyC-nOEZ5EE15_p-A@mail.gmail.com>

вт, 28 апр. 2020 г. в 01:29, gz <nginx-forum на forum.nginx.org>:

> > > Maxim Dounin Wrote:
> > > -------------------------------------------------------
> > > > > В HTML страницы бэкендом выдаются элементы <link rel="preload">
> > с
> > > > указанием
> > > > > на ресурсы для предзагрузки.
> > > > > Хотелось бы перейти с предзагрузки на http2_push указанных
> > ресурсов.
> > > >
> > > > А вы пробовали тестировать, что вы получите на выходе?
> > >
> > > Практически не проверял, но здравый смысл подсказывает, что даже в
> > рамках
> > > HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить
> > минимум
> > > один запрос на получение ресурсов, объявленных в <link
> > rel="preload">.
> >
> > Здравый смысл тут подсказывает неправильно. Поскольку сервер не
> > знает, какие ресурсы уже есть у клиента, а каких ещё нет, он шлёт
> > push'ы всегда, и тем самым расходует как канал, так и лишние
> > ресурсы на сервере. Соответственно результат будет зависеть от
> > того, насколько польза от push'а (сэкономленный 1 rtt при запросе
> > дополнительных ресурсов у тех клиентов, у которых этих ресурсов
> > нет) больше или меньше тех проблем, которые push добавляет всем
> > остальным клиентам.
>
> Востребованные ресурсы из push-кэша переходят в основной и будут
> использованы для следующих страниц.
> Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся в
> кэше.
> В крайнем случае несложно пометить клиента стандартным способом через
> cookie.
>
> > > > Имеющиеся исследования про эффективность HTTP/2 push позволяют
> > предолжить,
> > >
> > > > что результат скорее всего будет хуже, чем то, что у вас есть
> > > > сейчас.
> > >
> > > Я встречал обратные исследования.
> > > https://dexecure.com/blog/http2-push-vs-http-preload/
> >
> > По ссылке нет исследований, там только общие соображения.
> > Исследования выглядят как-то так:
> >
> >
>
> https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf
>
> Не совсем понимаю какие выводы делают авторы.
>
> Предлагают работать над приоритезацией (которая и так корректная, и
> регулируется preload'ом), использовать экспериментальный QUIC, поддержики
> которого толком нет.
>
> > > Плюс у push шире поддерживается.
> >
> > Я бы не был столь категоричен.
>
> Нет никакой категоричности:
> https://caniuse.com/#search=rel%20preload — 84%
> https://caniuse.com/#feat=http2 — 94%
>
> Не совсем корректное сравнение точно preload vs push, тем не менее.
>
> Я прекрасно понимаю, что push — не панацея, и хотел попробовать на практике
> проталкивание критических ресурсов, которые в любом случае приоритетны и
> будут загружены для отрисовки.
>

я бы с интересом посмотрел на аналитику, которая привела к такому развитию
событий.
какие метрики вы с приложения снимаете, методика, всё вот это.


>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,287846,287852#msg-287852
>
> _______________________________________________
> 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/20200428/d0fd2f71/attachment.htm>

From nginx-forum на forum.nginx.org  Mon Apr 27 22:59:09 2020
From: nginx-forum на forum.nginx.org (yyyuuu)
Date: Mon, 27 Apr 2020 18:59:09 -0400
Subject: =?UTF-8?B?Tmdpbngg0L/QtdGA0LXQvdCw0L/RgNCw0LLQu9C10L3QuNC1INC90LAg0LTRgNGD?=
 =?UTF-8?B?0LPQvtC5INCw0LTRgNC10YE=?=
Message-ID: <7392647de857488a3ab2209713d4bd7a.NginxMailingListRussian@forum.nginx.org>

Здравствуйте друзья, есть сервер "03" на нем стоит Nginx. Я хочу чтобы он
делал все поиски которые осуществляются на яндексе перенаправлялись на гугл,
со всем компутеров в домене


Код
worker_processes 1;
 
error_log logs/error.log;
 
events {
  worker_connections 1024;
}
 

http {
  include mime.types;
  default_type application/octet-stream;
  sendfile on;
  keepalive_timeout 65;
  gzip on;



	server {
        listen          80;
        server_name     ya.ru www.ya.ru;
        return 301 https://www.google.ru;
    }
}
Но оно не работает так как Я хочу.
В логах
Код
2020/04/22 10:44:29 [notice] 2184#1820: signal process started

Допустим название сервера "Третий"
Обращаюсь к нему со своего компа http://Трейти/new-name
При обращение Я получаю к "Трейтий" Я уже получаю доступ к адресу
http://192.168.1.1/new-name.
То есть все запросы которые идут на http://третий .. используютися на
локальных компутерах как http://192.168.1.1/new-name.

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


From nginx-forum на forum.nginx.org  Mon Apr 27 23:19:19 2020
From: nginx-forum на forum.nginx.org (S.A.N)
Date: Mon, 27 Apr 2020 19:19:19 -0400
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <52b8986c257de5e0bfe4e7e9ed5792c8.NginxMailingListRussian@forum.nginx.org>
References: <20200427191550.GS20357@mdounin.ru>
 <52b8986c257de5e0bfe4e7e9ed5792c8.NginxMailingListRussian@forum.nginx.org>
Message-ID: <69c608b37520c975cabbb7d89a29976d.NginxMailingListRussian@forum.nginx.org>

> В крайнем случае несложно пометить клиента стандартным способом через
> cookie.

Советую смотреть не на куки, а на наличия клиенских заголовков -
If-None-Match и/или If-Modified-Since, только при отсутствии или не
валидности данных заголовков делать push.
Из нашего опыта - push полезен только для клиентов у которых нет валидного
кеша, в этом случаи вы получите не большой прирост в скорости около 5-10%.

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


From mdounin на mdounin.ru  Tue Apr 28 00:08:52 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 28 Apr 2020 03:08:52 +0300
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <52b8986c257de5e0bfe4e7e9ed5792c8.NginxMailingListRussian@forum.nginx.org>
References: <20200427191550.GS20357@mdounin.ru>
 <52b8986c257de5e0bfe4e7e9ed5792c8.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200428000852.GT20357@mdounin.ru>

Hello!

On Mon, Apr 27, 2020 at 04:29:44PM -0400, gz wrote:

> > > Maxim Dounin Wrote:
> > > -------------------------------------------------------
> > > > > В HTML страницы бэкендом выдаются элементы <link rel="preload">
> > с
> > > > указанием
> > > > > на ресурсы для предзагрузки.
> > > > > Хотелось бы перейти с предзагрузки на http2_push указанных
> > ресурсов.
> > > > 
> > > > А вы пробовали тестировать, что вы получите на выходе?
> > > 
> > > Практически не проверял, но здравый смысл подсказывает, что даже в
> > рамках
> > > HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить
> > минимум
> > > один запрос на получение ресурсов, объявленных в <link
> > rel="preload">.
> > 
> > Здравый смысл тут подсказывает неправильно. Поскольку сервер не 
> > знает, какие ресурсы уже есть у клиента, а каких ещё нет, он шлёт 
> > push'ы всегда, и тем самым расходует как канал, так и лишние 
> > ресурсы на сервере. Соответственно результат будет зависеть от 
> > того, насколько польза от push'а (сэкономленный 1 rtt при запросе 
> > дополнительных ресурсов у тех клиентов, у которых этих ресурсов 
> > нет) больше или меньше тех проблем, которые push добавляет всем 
> > остальным клиентам.
> 
> Востребованные ресурсы из push-кэша переходят в основной и будут
> использованы для следующих страниц.
> Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся в
> кэше.
> В крайнем случае несложно пометить клиента стандартным способом через
> cookie.

Проблема в том, что даже отказ от push-ресурсов - это нагрузка как 
на сервер, так и на канал.  И статистика как бы говорит нам, что в 
среднем эти накладные расходы - больше, чем польза.

Что будет конкретно в вашем случае - зависит, безусловно, от 
конкретной нагрузки и от того, насколько "в крайнем случае 
несложно" вам будет избежать лишних push'ей.  Но, повторюсь, в 
среднем - будет хуже, потому что "в крайнем случае" никто не 
заморачивается.  Именно поэтому я начал с вопроса пробовали ли вы 
тестировать, что получится.  Подозреваю, что от банального 
перекладывания существующих <link rel="preload"> в push'ы - 
станет только хуже.

> > > > Имеющиеся исследования про эффективность HTTP/2 push позволяют
> > предолжить,
> > > 
> > > > что результат скорее всего будет хуже, чем то, что у вас есть 
> > > > сейчас.
> > > 
> > > Я встречал обратные исследования.
> > > https://dexecure.com/blog/http2-push-vs-http-preload/
> > 
> > По ссылке нет исследований, там только общие соображения.  
> > Исследования выглядят как-то так:
> > 
> >
> https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf
> 
> Не совсем понимаю какие выводы делают авторы.
> 
> Предлагают работать над приоритезацией (которая и так корректная, и
> регулируется preload'ом), использовать экспериментальный QUIC, поддержики
> которого толком нет.

Авторы ясно и однозначно показывают, что server push - в среднем 
вредит, и в большинстве случаев лишь способ выстрелить себе в 
ногу.  И предлагают работать над другими технологиями, 
потенциально более полезными.

Тут важно понимать, что речь идёт про взгляд разработчиков 
браузера, и рассказывалось это всё на HTTP working group, то есть 
в рамках встречи людей, занимающихся разработкой протокола.

(Ну и да, про приоритезацию - смешно.  Нет, это не про preload, 
это, как я понимаю, про приоритеты в рамках HTTP/2.  Там самолёт с 
бассейном и джакузи запроектирован в рамках стандарта, корректности 
ждать не приходится.)

> > > Плюс у push шире поддерживается.
> > 
> > Я бы не был столь категоричен. 
> 
> Нет никакой категоричности:
> https://caniuse.com/#search=rel%20preload — 84%
> https://caniuse.com/#feat=http2 — 94%
> 
> Не совсем корректное сравнение точно preload vs push, тем не менее.

Ну вот это сравнение - говорит о минимальной разнице, и при этом 
мы не знаем, сколько в том http2 поддержики push'а, и не знаем, 
сколько глюков там, где она таки есть.

> Я прекрасно понимаю, что push — не панацея, и хотел попробовать на практике
> проталкивание критических ресурсов, которые в любом случае приоритетны и
> будут загружены для отрисовки.

Именно с этого я и начал: попробуйте на практике на отдельных 
страницах, без попыток вытаскивать версии ресурсов через SSI и вот 
этого всего.  Получите статистику, сравните.

Сейчас же вы пришли и убеждаете разработчиков, что вам надо, 
потому что оно точно будет лучше, но тестировать вы ничего не 
тестировали и не хотите.  Так это не работает.  Придёте со 
стастикой, явно показывающей плюсы - мы задумаемся над тем, как 
облегчить вам жизнь в конфигурации с SSI.  Пока же из статистике 
есть вот только ссылка выше, из которой явно следует, что делать 
что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно.

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

From valery+nginxru на grid.net.ru  Tue Apr 28 12:19:48 2020
From: valery+nginxru на grid.net.ru (Valery Kholodkov)
Date: Tue, 28 Apr 2020 14:19:48 +0200
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <52b8986c257de5e0bfe4e7e9ed5792c8.NginxMailingListRussian@forum.nginx.org>
References: <20200427191550.GS20357@mdounin.ru>
 <52b8986c257de5e0bfe4e7e9ed5792c8.NginxMailingListRussian@forum.nginx.org>
Message-ID: <d193082a-fee1-2e68-ae58-a54c3ca2b6f0@grid.net.ru>

On 27-04-2020 22:29, gz wrote:
> https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf
> 
> Не совсем понимаю какие выводы делают авторы.

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

-- 
Val

From chipitsine на gmail.com  Tue Apr 28 12:59:39 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 28 Apr 2020 17:59:39 +0500
Subject: =?UTF-8?B?UmU6INCn0YLQviDQstGL0LHRgNCw0YLRjCBsb2NhdGlvbiDQuNC70LggcmV3cml0?=
 =?UTF-8?B?ZT8=?=
In-Reply-To: <8213ced3bf20ef8d60974ae57a7079f5.NginxMailingListRussian@forum.nginx.org>
References: <d3ee7378e4bacb36479551d60a81b7ea.NginxMailingListRussian@forum.nginx.org>
 <3fbc4e02f9c1b29df2c01eaafa69081e.NginxMailingListRussian@forum.nginx.org>
 <c4120804e90fb2c59593da8949a79c37.NginxMailingListRussian@forum.nginx.org>
 <8213ced3bf20ef8d60974ae57a7079f5.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQEtYcUiBS=MzK-egTk3O2bGpsCvDMRyRjnZTRNYxZ5Pow@mail.gmail.com>

сб, 25 апр. 2020 г. в 17:23, grey <nginx-forum на forum.nginx.org>:

> А если будет два десятка правил rewrite до секций location, не будет ли это
> сильно влиять на производительность? Или опять таки php больше грузит
> сервер, чем nginx и можно этим пренебречь?
>

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




>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,287729,287809#msg-287809
>
> _______________________________________________
> 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/20200428/d859c794/attachment.htm>

From mdounin на mdounin.ru  Tue Apr 28 16:13:10 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 28 Apr 2020 19:13:10 +0300
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <d193082a-fee1-2e68-ae58-a54c3ca2b6f0@grid.net.ru>
References: <20200427191550.GS20357@mdounin.ru>
 <52b8986c257de5e0bfe4e7e9ed5792c8.NginxMailingListRussian@forum.nginx.org>
 <d193082a-fee1-2e68-ae58-a54c3ca2b6f0@grid.net.ru>
Message-ID: <20200428161310.GU20357@mdounin.ru>

Hello!

On Tue, Apr 28, 2020 at 02:19:48PM +0200, Valery Kholodkov wrote:

> On 27-04-2020 22:29, gz wrote:
> > https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf
> > 
> > Не совсем понимаю какие выводы делают авторы.
> 
> Мне, кроме того, и непонятно где автор взял исходные данные.

На четвёртом слайде английским по белому: это данные из 
экспериментов в beta-канале Chrome.

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

From nginx-forum на forum.nginx.org  Wed Apr 29 16:46:23 2020
From: nginx-forum на forum.nginx.org (gewisser)
Date: Wed, 29 Apr 2020 12:46:23 -0400
Subject: =?UTF-8?Q?Re=3A_Windows_=D0=B8_upstream_php-cgi=2Eexe?=
In-Reply-To: <42ce03341c98932dce8b4a660084e3af.NginxMailingListRussian@forum.nginx.org>
References: <20200406124307.GM20357@mdounin.ru>
 <42ce03341c98932dce8b4a660084e3af.NginxMailingListRussian@forum.nginx.org>
Message-ID: <e9fcabc457682cab0bb70a4ffc35b65d.NginxMailingListRussian@forum.nginx.org>

Есть какая-нибудь возможность отправить "Connection: close"?

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


From nginx-forum на forum.nginx.org  Wed Apr 29 17:25:55 2020
From: nginx-forum на forum.nginx.org (gz)
Date: Wed, 29 Apr 2020 13:25:55 -0400
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <69c608b37520c975cabbb7d89a29976d.NginxMailingListRussian@forum.nginx.org>
References: <20200427191550.GS20357@mdounin.ru>
 <52b8986c257de5e0bfe4e7e9ed5792c8.NginxMailingListRussian@forum.nginx.org>
 <69c608b37520c975cabbb7d89a29976d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <146084e47d90b72e5f6f25079cf491f0.NginxMailingListRussian@forum.nginx.org>

> Советую смотреть не на куки, а на наличия клиенских заголовков -
> If-None-Match и/или If-Modified-Since, только при отсутствии или не
> валидности данных заголовков делать push.
> Из нашего опыта - push полезен только для клиентов у которых нет
> валидного кеша, в этом случаи вы получите не большой прирост в
> скорости около 5-10%.

Не совсем понимаю Ваш совет.

Решение о push'е принимается при генерации HTML-ответа за запрос к
странице.
В этот момент доступны If-None-Match и/или If-Modified-Since только самой
страницы и странно ориентироваться на них, так как они ничего не говорят о
наличии в кэше клиента тех ресурсов, которые мы планируем протолкнуть в
ответе.

А если поступит conditional-get-запрос к самому ресурсу, то что-либо делать
с push'ем уже поздно.

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


From nginx-forum на forum.nginx.org  Wed Apr 29 17:26:27 2020
From: nginx-forum на forum.nginx.org (gz)
Date: Wed, 29 Apr 2020 13:26:27 -0400
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <20200428000852.GT20357@mdounin.ru>
References: <20200428000852.GT20357@mdounin.ru>
Message-ID: <4cf73b253991d2b0847469dc35de60cd.NginxMailingListRussian@forum.nginx.org>

> > Востребованные ресурсы из push-кэша переходят в основной и будут
> > использованы для следующих страниц.
> > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся
> в
> > кэше.
> > В крайнем случае несложно пометить клиента стандартным способом
> через
> > cookie.
> 
> Проблема в том, что даже отказ от push-ресурсов - это нагрузка как 
> на сервер, так и на канал.  И статистика как бы говорит нам, что в 
> среднем эти накладные расходы - больше, чем польза.

Я таковой статистикой не располагаю.
Но предполагаю, что клиенту отказаться от push'а проще, чем сделать
дополнительный запрос к ресурсу.

> Что будет конкретно в вашем случае - зависит, безусловно, от 
> конкретной нагрузки и от того, насколько "в крайнем случае 
> несложно" вам будет избежать лишних push'ей.  Но, повторюсь, в 
> среднем - будет хуже, потому что "в крайнем случае" никто не 
> заморачивается.  Именно поэтому я начал с вопроса пробовали ли вы 
> тестировать, что получится.  Подозреваю, что от банального 
> перекладывания существующих <link rel="preload"> в push'ы - 
> станет только хуже.

Да, я понял Вашу точку зрения.
Да, узкого эксперимента я не проводил.

>
https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf
> > 
> > Не совсем понимаю какие выводы делают авторы.
> > 
> > Предлагают работать над приоритезацией (которая и так корректная, и
> > регулируется preload'ом), использовать экспериментальный QUIC,
> поддержики
> > которого толком нет.
> 
> Авторы ясно и однозначно показывают, что server push - в среднем 
> вредит, и в большинстве случаев лишь способ выстрелить себе в 
> ногу.  И предлагают работать над другими технологиями, 
> потенциально более полезными.
> 
> Тут важно понимать, что речь идёт про взгляд разработчиков 
> браузера, и рассказывалось это всё на HTTP working group, то есть 
> в рамках встречи людей, занимающихся разработкой протокола.

Из Ваших соображений и трактовке вышеприведённого исследования складывается
впечатление, что даже разработчики протокола не донца понимают зачем push
нужен.
При том, что не только они описали его в протоколе, но и сторонние
разработчики реализовали поддержку push'а клиентах и нескольких серверах.

> (Ну и да, про приоритезацию - смешно.  Нет, это не про preload, 
> это, как я понимаю, про приоритеты в рамках HTTP/2.  Там самолёт с 
> бассейном и джакузи запроектирован в рамках стандарта, корректности 
> ждать не приходится.)

Я о текущей примитивной приоретизации.
Сомневаюсь, что когда-нибудь появятся инстументы точного управления ею,
браузеры всё равно будут вынуждены использовать указания как рекомендацию.

> > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на
> практике
> > проталкивание критических ресурсов, которые в любом случае
> приоритетны и
> > будут загружены для отрисовки.
> 
> Именно с этого я и начал: попробуйте на практике на отдельных 
> страницах, без попыток вытаскивать версии ресурсов через SSI и вот 
> этого всего.  Получите статистику, сравните.
> 
> Сейчас же вы пришли и убеждаете разработчиков, что вам надо, 
> потому что оно точно будет лучше, но тестировать вы ничего не 
> тестировали и не хотите. 

Где именно и кого я в чём-то убеждал и убеждал в том, что мне нужно?
Я задал вопрос о планах.

А учитывая, что использовать саму директиву http2_push затруднительно — один
ресурс за раз, невозможность использования в if — и предвидя рекомендацию
использовать http2_push_preload, я рассказал о том, в какую сторону пошёл и
что уже попробовал сделать своими силами, и о том, какие возможности могли
бы помочь в решении задачи.

> Так это не работает.  Придёте со 
> стастикой, явно показывающей плюсы - мы задумаемся над тем, как 
> облегчить вам жизнь в конфигурации с SSI.  Пока же из статистике 
> есть вот только ссылка выше, из которой явно следует, что делать 
> что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно.

То, о чём я рассказываю и есть эксперимент.
Проще внедрить это на dev- или даже production-версии сайта, чем готовить
узкие эксперименты из двух страниц.
В случае pdocution'а можно прогнозировать значимое изменение в статистике
загрузки страниц, в том числе по данным браузеров — в той же Метрике, Google
Console или PageSpeed Insights.

Простой эксперимент, конечно, имеет право на жизнь, но это пара страниц и
несколько доступных браузеров и инструментов.

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


From chipitsine на gmail.com  Wed Apr 29 17:41:29 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 29 Apr 2020 22:41:29 +0500
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <4cf73b253991d2b0847469dc35de60cd.NginxMailingListRussian@forum.nginx.org>
References: <20200428000852.GT20357@mdounin.ru>
 <4cf73b253991d2b0847469dc35de60cd.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQGTn85tQBRZUbq-UuMpKxC0nsstT2LOcW0SwhbkST1T1w@mail.gmail.com>

ср, 29 апр. 2020 г. в 22:26, gz <nginx-forum на forum.nginx.org>:

> > > Востребованные ресурсы из push-кэша переходят в основной и будут
> > > использованы для следующих страниц.
> > > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся
> > в
> > > кэше.
> > > В крайнем случае несложно пометить клиента стандартным способом
> > через
> > > cookie.
> >
> > Проблема в том, что даже отказ от push-ресурсов - это нагрузка как
> > на сервер, так и на канал.  И статистика как бы говорит нам, что в
> > среднем эти накладные расходы - больше, чем польза.
>
> Я таковой статистикой не располагаю.
> Но предполагаю, что клиенту отказаться от push'а проще, чем сделать
> дополнительный запрос к ресурсу.
>
> > Что будет конкретно в вашем случае - зависит, безусловно, от
> > конкретной нагрузки и от того, насколько "в крайнем случае
> > несложно" вам будет избежать лишних push'ей.  Но, повторюсь, в
> > среднем - будет хуже, потому что "в крайнем случае" никто не
> > заморачивается.  Именно поэтому я начал с вопроса пробовали ли вы
> > тестировать, что получится.  Подозреваю, что от банального
> > перекладывания существующих <link rel="preload"> в push'ы -
> > станет только хуже.
>
> Да, я понял Вашу точку зрения.
> Да, узкого эксперимента я не проводил.
>
> >
>
> https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf
> > >
> > > Не совсем понимаю какие выводы делают авторы.
> > >
> > > Предлагают работать над приоритезацией (которая и так корректная, и
> > > регулируется preload'ом), использовать экспериментальный QUIC,
> > поддержики
> > > которого толком нет.
> >
> > Авторы ясно и однозначно показывают, что server push - в среднем
> > вредит, и в большинстве случаев лишь способ выстрелить себе в
> > ногу.  И предлагают работать над другими технологиями,
> > потенциально более полезными.
> >
> > Тут важно понимать, что речь идёт про взгляд разработчиков
> > браузера, и рассказывалось это всё на HTTP working group, то есть
> > в рамках встречи людей, занимающихся разработкой протокола.
>
> Из Ваших соображений и трактовке вышеприведённого исследования складывается
> впечатление, что даже разработчики протокола не донца понимают зачем push
> нужен.
> При том, что не только они описали его в протоколе, но и сторонние
> разработчики реализовали поддержку push'а клиентах и нескольких серверах.
>
> > (Ну и да, про приоритезацию - смешно.  Нет, это не про preload,
> > это, как я понимаю, про приоритеты в рамках HTTP/2.  Там самолёт с
> > бассейном и джакузи запроектирован в рамках стандарта, корректности
> > ждать не приходится.)
>
> Я о текущей примитивной приоретизации.
> Сомневаюсь, что когда-нибудь появятся инстументы точного управления ею,
> браузеры всё равно будут вынуждены использовать указания как рекомендацию.
>
> > > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на
> > практике
> > > проталкивание критических ресурсов, которые в любом случае
> > приоритетны и
> > > будут загружены для отрисовки.
> >
> > Именно с этого я и начал: попробуйте на практике на отдельных
> > страницах, без попыток вытаскивать версии ресурсов через SSI и вот
> > этого всего.  Получите статистику, сравните.
> >
> > Сейчас же вы пришли и убеждаете разработчиков, что вам надо,
> > потому что оно точно будет лучше, но тестировать вы ничего не
> > тестировали и не хотите.
>
> Где именно и кого я в чём-то убеждал и убеждал в том, что мне нужно?
> Я задал вопрос о планах.
>
> А учитывая, что использовать саму директиву http2_push затруднительно —
> один
> ресурс за раз, невозможность использования в if — и предвидя рекомендацию
> использовать http2_push_preload, я рассказал о том, в какую сторону пошёл и
> что уже попробовал сделать своими силами, и о том, какие возможности могли
> бы помочь в решении задачи.
>
> > Так это не работает.  Придёте со
> > стастикой, явно показывающей плюсы - мы задумаемся над тем, как
> > облегчить вам жизнь в конфигурации с SSI.  Пока же из статистике
> > есть вот только ссылка выше, из которой явно следует, что делать
> > что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно.
>
> То, о чём я рассказываю и есть эксперимент.
> Проще внедрить это на dev- или даже production-версии сайта, чем готовить
> узкие эксперименты из двух страниц.
>

у вас же должны быть логи по html страницам и по css-файлам. посмотрите на
них.
если

а) у вас хорошее кеширование (т.е. ноль 304-х)
б) количество ответов css соответствует количеству отданных html страниц

то, вероятно, в вашем случае будет профит от того, что сделаете push на css
ну и наоборот, если css отдается меньше, или отдается столько же, но много
304-х,
то выигрыш будет отрицательный



> В случае pdocution'а можно прогнозировать значимое изменение в статистике
> загрузки страниц, в том числе по данным браузеров — в той же Метрике,
> Google
> Console или PageSpeed Insights.
>
> Простой эксперимент, конечно, имеет право на жизнь, но это пара страниц и
> несколько доступных браузеров и инструментов.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,287846,287886#msg-287886
>
> _______________________________________________
> 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/20200429/abd94b08/attachment-0001.htm>

From alex.hha на gmail.com  Wed Apr 29 18:39:34 2020
From: alex.hha на gmail.com (Alex Domoradov)
Date: Wed, 29 Apr 2020 21:39:34 +0300
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <CAFHpkQGTn85tQBRZUbq-UuMpKxC0nsstT2LOcW0SwhbkST1T1w@mail.gmail.com>
References: <20200428000852.GT20357@mdounin.ru>
 <4cf73b253991d2b0847469dc35de60cd.NginxMailingListRussian@forum.nginx.org>
 <CAFHpkQGTn85tQBRZUbq-UuMpKxC0nsstT2LOcW0SwhbkST1T1w@mail.gmail.com>
Message-ID: <CAK90gp7CAUj2aPfDTsWQxtXk-6=kWN8PVMY=tJcSb0z6pCWP-Q@mail.gmail.com>

> то выигрыш будет отрицательный

у меня эта фраза вызывает когнитивный диссонанс

On Wed, Apr 29, 2020 at 8:41 PM Илья Шипицин <chipitsine на gmail.com> wrote:

>
>
> ср, 29 апр. 2020 г. в 22:26, gz <nginx-forum на forum.nginx.org>:
>
>> > > Востребованные ресурсы из push-кэша переходят в основной и будут
>> > > использованы для следующих страниц.
>> > > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся
>> > в
>> > > кэше.
>> > > В крайнем случае несложно пометить клиента стандартным способом
>> > через
>> > > cookie.
>> >
>> > Проблема в том, что даже отказ от push-ресурсов - это нагрузка как
>> > на сервер, так и на канал.  И статистика как бы говорит нам, что в
>> > среднем эти накладные расходы - больше, чем польза.
>>
>> Я таковой статистикой не располагаю.
>> Но предполагаю, что клиенту отказаться от push'а проще, чем сделать
>> дополнительный запрос к ресурсу.
>>
>> > Что будет конкретно в вашем случае - зависит, безусловно, от
>> > конкретной нагрузки и от того, насколько "в крайнем случае
>> > несложно" вам будет избежать лишних push'ей.  Но, повторюсь, в
>> > среднем - будет хуже, потому что "в крайнем случае" никто не
>> > заморачивается.  Именно поэтому я начал с вопроса пробовали ли вы
>> > тестировать, что получится.  Подозреваю, что от банального
>> > перекладывания существующих <link rel="preload"> в push'ы -
>> > станет только хуже.
>>
>> Да, я понял Вашу точку зрения.
>> Да, узкого эксперимента я не проводил.
>>
>> >
>>
>> https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf
>> > >
>> > > Не совсем понимаю какие выводы делают авторы.
>> > >
>> > > Предлагают работать над приоритезацией (которая и так корректная, и
>> > > регулируется preload'ом), использовать экспериментальный QUIC,
>> > поддержики
>> > > которого толком нет.
>> >
>> > Авторы ясно и однозначно показывают, что server push - в среднем
>> > вредит, и в большинстве случаев лишь способ выстрелить себе в
>> > ногу.  И предлагают работать над другими технологиями,
>> > потенциально более полезными.
>> >
>> > Тут важно понимать, что речь идёт про взгляд разработчиков
>> > браузера, и рассказывалось это всё на HTTP working group, то есть
>> > в рамках встречи людей, занимающихся разработкой протокола.
>>
>> Из Ваших соображений и трактовке вышеприведённого исследования
>> складывается
>> впечатление, что даже разработчики протокола не донца понимают зачем push
>> нужен.
>> При том, что не только они описали его в протоколе, но и сторонние
>> разработчики реализовали поддержку push'а клиентах и нескольких серверах.
>>
>> > (Ну и да, про приоритезацию - смешно.  Нет, это не про preload,
>> > это, как я понимаю, про приоритеты в рамках HTTP/2.  Там самолёт с
>> > бассейном и джакузи запроектирован в рамках стандарта, корректности
>> > ждать не приходится.)
>>
>> Я о текущей примитивной приоретизации.
>> Сомневаюсь, что когда-нибудь появятся инстументы точного управления ею,
>> браузеры всё равно будут вынуждены использовать указания как рекомендацию.
>>
>> > > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на
>> > практике
>> > > проталкивание критических ресурсов, которые в любом случае
>> > приоритетны и
>> > > будут загружены для отрисовки.
>> >
>> > Именно с этого я и начал: попробуйте на практике на отдельных
>> > страницах, без попыток вытаскивать версии ресурсов через SSI и вот
>> > этого всего.  Получите статистику, сравните.
>> >
>> > Сейчас же вы пришли и убеждаете разработчиков, что вам надо,
>> > потому что оно точно будет лучше, но тестировать вы ничего не
>> > тестировали и не хотите.
>>
>> Где именно и кого я в чём-то убеждал и убеждал в том, что мне нужно?
>> Я задал вопрос о планах.
>>
>> А учитывая, что использовать саму директиву http2_push затруднительно —
>> один
>> ресурс за раз, невозможность использования в if — и предвидя рекомендацию
>> использовать http2_push_preload, я рассказал о том, в какую сторону пошёл
>> и
>> что уже попробовал сделать своими силами, и о том, какие возможности могли
>> бы помочь в решении задачи.
>>
>> > Так это не работает.  Придёте со
>> > стастикой, явно показывающей плюсы - мы задумаемся над тем, как
>> > облегчить вам жизнь в конфигурации с SSI.  Пока же из статистике
>> > есть вот только ссылка выше, из которой явно следует, что делать
>> > что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно.
>>
>> То, о чём я рассказываю и есть эксперимент.
>> Проще внедрить это на dev- или даже production-версии сайта, чем готовить
>> узкие эксперименты из двух страниц.
>>
>
> у вас же должны быть логи по html страницам и по css-файлам. посмотрите на
> них.
> если
>
> а) у вас хорошее кеширование (т.е. ноль 304-х)
> б) количество ответов css соответствует количеству отданных html страниц
>
> то, вероятно, в вашем случае будет профит от того, что сделаете push на css
> ну и наоборот, если css отдается меньше, или отдается столько же, но много
> 304-х,
> то выигрыш будет отрицательный
>
>
>
>> В случае pdocution'а можно прогнозировать значимое изменение в статистике
>> загрузки страниц, в том числе по данным браузеров — в той же Метрике,
>> Google
>> Console или PageSpeed Insights.
>>
>> Простой эксперимент, конечно, имеет право на жизнь, но это пара страниц и
>> несколько доступных браузеров и инструментов.
>>
>> Posted at Nginx Forum:
>> https://forum.nginx.org/read.php?21,287846,287886#msg-287886
>>
>> _______________________________________________
>> 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
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200429/69b634ea/attachment-0001.htm>

From mdounin на mdounin.ru  Wed Apr 29 18:56:15 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 29 Apr 2020 21:56:15 +0300
Subject: =?UTF-8?Q?Re=3A_Windows_=D0=B8_upstream_php-cgi=2Eexe?=
In-Reply-To: <e9fcabc457682cab0bb70a4ffc35b65d.NginxMailingListRussian@forum.nginx.org>
References: <20200406124307.GM20357@mdounin.ru>
 <42ce03341c98932dce8b4a660084e3af.NginxMailingListRussian@forum.nginx.org>
 <e9fcabc457682cab0bb70a4ffc35b65d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200429185615.GV20357@mdounin.ru>

Hello!

On Wed, Apr 29, 2020 at 12:46:23PM -0400, gewisser wrote:

> Есть какая-нибудь возможность отправить "Connection: close"?

Я об этом писал в самом первом ответе - в конфиге nginx'а 
выключить keepalive с помощью директивы keepalive_timeout
(http://nginx.org/r/keepalive_timeout/ru).

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

From bgx на protva.ru  Wed Apr 29 19:00:27 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Wed, 29 Apr 2020 22:00:27 +0300
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <4cf73b253991d2b0847469dc35de60cd.NginxMailingListRussian@forum.nginx.org>
References: <20200428000852.GT20357@mdounin.ru>
 <4cf73b253991d2b0847469dc35de60cd.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200429190027.GC2616@sie.protva.ru>

On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote:
> Но предполагаю, что клиенту отказаться от push'а проще, чем сделать
> дополнительный запрос к ресурсу.

 Если клиент умеет cache digest, то да, может отказаться заранее.
 А если нет, то к тому моменту, когда клиент сможет отклонить push,
 данные уже летят по сети и отъедают пропускную способность канала,
 это обстоятельство может навредить желанию загрузить все причандалы
 к странице побыстрее.

 Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю
 профит от сложной и очень тяжёлой технологии". И push в том ряду.
-- 
 Eugene Berdnikov

From chipitsine на gmail.com  Wed Apr 29 20:41:13 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 30 Apr 2020 01:41:13 +0500
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <20200429190027.GC2616@sie.protva.ru>
References: <20200428000852.GT20357@mdounin.ru>
 <4cf73b253991d2b0847469dc35de60cd.NginxMailingListRussian@forum.nginx.org>
 <20200429190027.GC2616@sie.protva.ru>
Message-ID: <CAFHpkQEmZj1jL+p3fBi8uY75ptwB3TdyFJSSF4-z5yiQxaTNUg@mail.gmail.com>

чт, 30 апр. 2020 г. в 00:00, Evgeniy Berdnikov <bgx на protva.ru>:

> On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote:
> > Но предполагаю, что клиенту отказаться от push'а проще, чем сделать
> > дополнительный запрос к ресурсу.
>
>  Если клиент умеет cache digest, то да, может отказаться заранее.
>  А если нет, то к тому моменту, когда клиент сможет отклонить push,
>  данные уже летят по сети и отъедают пропускную способность канала,
>  это обстоятельство может навредить желанию загрузить все причандалы
>  к странице побыстрее.
>
>  Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю
>  профит от сложной и очень тяжёлой технологии". И push в том ряду.
>


http2 решает искуственную проблему - у браузера по каким-то странным
причинам ограничего количество одновременных
tcp сессий, обычно двумя сессиями. И, допустим, браузер параллельно тащит
два оооооочень медленных ответа, все остальные
элементы, как то css стили, которые нужны для того, чтобы отрендерить
страницу, на паузе.

т.е. браузер решил сам себе ограничить количество сессий - удачи ему.
а потом пришли разработчики http2 и сказали "а давайте внутри одной tcp
сессии будет типа еще один инкапсулированный tcp
с мультиплексированием". ну то есть нам дорого открыть несколько честных
tcp потоков, лучше мы заморочимся тем, что будем
мультиплексировать tcp внутри tcp.



насчет действительно связанных css и js - в принципе можно их эмбедить
прямо в html разметку. и отдавать вместе с основной страницей.
тот же push.



> --
>  Eugene Berdnikov
> _______________________________________________
> 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/20200430/30e1c551/attachment.htm>

From slw на zxy.spb.ru  Wed Apr 29 20:59:01 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Wed, 29 Apr 2020 23:59:01 +0300
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <CAFHpkQEmZj1jL+p3fBi8uY75ptwB3TdyFJSSF4-z5yiQxaTNUg@mail.gmail.com>
References: <20200428000852.GT20357@mdounin.ru>
 <4cf73b253991d2b0847469dc35de60cd.NginxMailingListRussian@forum.nginx.org>
 <20200429190027.GC2616@sie.protva.ru>
 <CAFHpkQEmZj1jL+p3fBi8uY75ptwB3TdyFJSSF4-z5yiQxaTNUg@mail.gmail.com>
Message-ID: <20200429205901.GA19231@zxy.spb.ru>

On Thu, Apr 30, 2020 at 01:41:13AM +0500, Илья Шипицин wrote:

> чт, 30 апр. 2020 г. в 00:00, Evgeniy Berdnikov <bgx на protva.ru>:
> 
> > On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote:
> > > Но предполагаю, что клиенту отказаться от push'а проще, чем сделать
> > > дополнительный запрос к ресурсу.
> >
> >  Если клиент умеет cache digest, то да, может отказаться заранее.
> >  А если нет, то к тому моменту, когда клиент сможет отклонить push,
> >  данные уже летят по сети и отъедают пропускную способность канала,
> >  это обстоятельство может навредить желанию загрузить все причандалы
> >  к странице побыстрее.
> >
> >  Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю
> >  профит от сложной и очень тяжёлой технологии". И push в том ряду.
> >
> 
> 
> http2 решает искуственную проблему - у браузера по каким-то странным
> причинам ограничего количество одновременных
> tcp сессий, обычно двумя сессиями. И, допустим, браузер параллельно тащит
> два оооооочень медленных ответа, все остальные
> элементы, как то css стили, которые нужны для того, чтобы отрендерить
> страницу, на паузе.
> 
> т.е. браузер решил сам себе ограничить количество сессий - удачи ему.
> а потом пришли разработчики http2 и сказали "а давайте внутри одной tcp
> сессии будет типа еще один инкапсулированный tcp
> с мультиплексированием". ну то есть нам дорого открыть несколько честных
> tcp потоков, лучше мы заморочимся тем, что будем
> мультиплексировать tcp внутри tcp.

нет-нет.
не так все было.
много соединений на сервер == много одновременных запросов == большая
нагрузка на сервер (особенно если там апач или томкат).
это же почти DDoS!

разработчики браузеров сказали -- а мы за все хорошее и против всего
плохого!
ограничим число одновоременных запросов от каждого браузера двумя!
фиг вам зловереды а не DDoS!

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

ну надеюсь теперь все догадываются что будет дальше?
подсказываю: зловредные страницы котрые будут содержать миллионы
ссылок на http2 сайты которые будут по двум соединениям делать 100500
одновременных запросов на разные ресурсы. после этого разработчки
браузеров разрешат по каждому http2 соединению делать не более 2
запосов.


From chipitsine на gmail.com  Wed Apr 29 22:14:57 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 30 Apr 2020 03:14:57 +0500
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <20200429205901.GA19231@zxy.spb.ru>
References: <20200428000852.GT20357@mdounin.ru>
 <4cf73b253991d2b0847469dc35de60cd.NginxMailingListRussian@forum.nginx.org>
 <20200429190027.GC2616@sie.protva.ru>
 <CAFHpkQEmZj1jL+p3fBi8uY75ptwB3TdyFJSSF4-z5yiQxaTNUg@mail.gmail.com>
 <20200429205901.GA19231@zxy.spb.ru>
Message-ID: <CAFHpkQH0oWV1GKbycYvsTNw9OgbenZGD9hUmqECPhQnm9==Zcw@mail.gmail.com>

чт, 30 апр. 2020 г. в 01:59, Slawa Olhovchenkov <slw на zxy.spb.ru>:

> On Thu, Apr 30, 2020 at 01:41:13AM +0500, Илья Шипицин wrote:
>
> > чт, 30 апр. 2020 г. в 00:00, Evgeniy Berdnikov <bgx на protva.ru>:
> >
> > > On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote:
> > > > Но предполагаю, что клиенту отказаться от push'а проще, чем сделать
> > > > дополнительный запрос к ресурсу.
> > >
> > >  Если клиент умеет cache digest, то да, может отказаться заранее.
> > >  А если нет, то к тому моменту, когда клиент сможет отклонить push,
> > >  данные уже летят по сети и отъедают пропускную способность канала,
> > >  это обстоятельство может навредить желанию загрузить все причандалы
> > >  к странице побыстрее.
> > >
> > >  Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю
> > >  профит от сложной и очень тяжёлой технологии". И push в том ряду.
> > >
> >
> >
> > http2 решает искуственную проблему - у браузера по каким-то странным
> > причинам ограничего количество одновременных
> > tcp сессий, обычно двумя сессиями. И, допустим, браузер параллельно тащит
> > два оооооочень медленных ответа, все остальные
> > элементы, как то css стили, которые нужны для того, чтобы отрендерить
> > страницу, на паузе.
> >
> > т.е. браузер решил сам себе ограничить количество сессий - удачи ему.
> > а потом пришли разработчики http2 и сказали "а давайте внутри одной tcp
> > сессии будет типа еще один инкапсулированный tcp
> > с мультиплексированием". ну то есть нам дорого открыть несколько честных
> > tcp потоков, лучше мы заморочимся тем, что будем
> > мультиплексировать tcp внутри tcp.
>
> нет-нет.
> не так все было.
> много соединений на сервер == много одновременных запросов == большая
> нагрузка на сервер (особенно если там апач или томкат).
> это же почти DDoS!
>


видимо, Слава забыл тег <sarcasm>
в приведенном (выдуманном) примере описано, что надо защищать сервер апач
от ддоса,
притом, что задача не позволить открыть больше конекшенов, чем сервер
способен осилить,
выглядит скорее, как задача самого сервера

но да, какая-то подобная логика вполне могла быть в этой всей истории.


>
> разработчики браузеров сказали -- а мы за все хорошее и против всего
> плохого!
> ограничим число одновоременных запросов от каждого браузера двумя!
> фиг вам зловереды а не DDoS!
>
> прошло некоторое время, все уже забыли почему так получилось и
> разрабочки стандарта придумали э... монстра.
>
> ну надеюсь теперь все догадываются что будет дальше?
> подсказываю: зловредные страницы котрые будут содержать миллионы
> ссылок на http2 сайты которые будут по двум соединениям делать 100500
> одновременных запросов на разные ресурсы. после этого разработчки
> браузеров разрешат по каждому http2 соединению делать не более 2
> запосов.
>
> _______________________________________________
> 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/20200430/19e86570/attachment-0001.htm>

From nginx-forum на forum.nginx.org  Wed Apr 29 23:33:41 2020
From: nginx-forum на forum.nginx.org (S.A.N)
Date: Wed, 29 Apr 2020 19:33:41 -0400
Subject: =?UTF-8?B?UmU6IGh0dHAyIHB1c2gg4oCUINC90LUg0L/Qu9Cw0L3QuNGA0YPQtdGC0YHRjyA=?=
 =?UTF-8?B?0LvQuCDQv9C+0LTQtNC10YDQttC60LAgPGxpbmsgcmVsPSJwcmVsb2FkIj4g?=
 =?UTF-8?B?0L/QviDQsNC90LDQu9C+0LPQuNC4INGBINC30LDQs9C+0LvQvtCy0LrQvtC8?=
 =?UTF-8?B?IExpbms/?=
In-Reply-To: <146084e47d90b72e5f6f25079cf491f0.NginxMailingListRussian@forum.nginx.org>
References: <20200427191550.GS20357@mdounin.ru>
 <52b8986c257de5e0bfe4e7e9ed5792c8.NginxMailingListRussian@forum.nginx.org>
 <69c608b37520c975cabbb7d89a29976d.NginxMailingListRussian@forum.nginx.org>
 <146084e47d90b72e5f6f25079cf491f0.NginxMailingListRussian@forum.nginx.org>
Message-ID: <4a0c59e377a1376190acf7b151359687.NginxMailingListRussian@forum.nginx.org>

> Решение о push'е принимается при генерации HTML-ответа за запрос к
> странице.
> В этот момент доступны If-None-Match и/или If-Modified-Since только
> самой страницы и странно ориентироваться на них, так как они ничего не
> говорят о наличии в кэше клиента тех ресурсов, которые мы планируем
> протолкнуть в ответе.

Дело в том, что в этом ответе на запрос (у вас это НТМЛ страница),
формируется url к ресурсам для push, если в эти url вы добавляете версии, вы
можете включить хеш всех версий ресурсов для push, в ETag заголовка ответа
НТМЛ страницы, тогда вы сможете сопоставлять клиенские заголовки
If-None-Match и актуальные версии ресурсов, если вы не можете детектить
валидность клиенского кеша для этих ресурсов, тогда лучше link без push.

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


From nginx-forum на forum.nginx.org  Thu Apr 30 07:06:40 2020
From: nginx-forum на forum.nginx.org (Luxerybelt)
Date: Thu, 30 Apr 2020 03:06:40 -0400
Subject: =?UTF-8?B?0J/QvtC80L7Qs9C40YLQtSDQutC+0L3QstC10YDRgtC40YDQvtCy0LDRgtGMIC5o?=
 =?UTF-8?B?dGFjY2VzcyDQsiDRhNCw0LnQuyAuY29uZiDQtNC70Y8gbmdpbngu?=
Message-ID: <417a65b93df9c52a690ad105c5674847.NginxMailingListRussian@forum.nginx.org>

Привет всем! Помогите конвертировать .htaccess в файл .conf для nginx.

Содержание .htaccess:

RewriteEngine On
Options -Indexes
<IfModule mod_headers.c>
  Header set Access-Control-Allow-Origin "*"
</IfModule>

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} (.+)/$
RewriteRule ^ %1 [R=301,L]

RewriteCond %{REQUEST_FILENAME} !-d 
RewriteCond %{REQUEST_FILENAME}\.php -f 
RewriteRule ^(.*)$ $1.php

RewriteCond %{THE_REQUEST} ^[A-Z]{3,}\s([^.]+)\.php [NC]
RewriteRule ^ %1 [R,L]

RewriteRule ^([0-9a-zA-Z-_-]+)$ user.php?seller_user_name=$1

RewriteCond %{HTTP_HOST} !=localhost
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule (.*) https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

#Now, rewrite to HTTPS if www present:
RewriteCond %{HTTPS} off
RewriteCond %{HTTP_HOST} !=localhost
RewriteCond %{HTTP_HOST} ^www\.
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Заранее благодарен.

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


From red-fox0 на ya.ru  Thu Apr 30 07:17:01 2020
From: red-fox0 на ya.ru (fox)
Date: Thu, 30 Apr 2020 14:17:01 +0700
Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUg0LrQvtC90LLQtdGA0YLQuNGA0L7QstCw0YI=?=
 =?UTF-8?B?0YwgLmh0YWNjZXNzINCyINGE0LDQudC7IC5jb25mINC00LvRjyBuZ2lueC4=?=
In-Reply-To: <417a65b93df9c52a690ad105c5674847.NginxMailingListRussian@forum.nginx.org>
References: <417a65b93df9c52a690ad105c5674847.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5e09826e-2dcd-bcdc-8185-3bfb95179ceb@ya.ru>

server {
  listen 80;
  server_name _;
  return 301 https://www.site.com$request_uri;

  # server_name site.com www.site.com;
  # return 301 https://$host$request_uri;
}

server {
  listen 443 ssl http2;
  server_name www.site.com;

  location / {
    add_header Access-Control-Allow-Origin "*";
  }


30.04.2020 14:06, Luxerybelt пишет:
> Привет всем! Помогите конвертировать .htaccess в файл .conf для nginx.
> 
> Содержание .htaccess:
> 
> RewriteEngine On
> Options -Indexes
> <IfModule mod_headers.c>
>   Header set Access-Control-Allow-Origin "*"
> </IfModule>
> 
> RewriteCond %{REQUEST_FILENAME} !-d
> RewriteCond %{REQUEST_URI} (.+)/$
> RewriteRule ^ %1 [R=301,L]
> 
> RewriteCond %{REQUEST_FILENAME} !-d 
> RewriteCond %{REQUEST_FILENAME}\.php -f 
> RewriteRule ^(.*)$ $1.php
> 
> RewriteCond %{THE_REQUEST} ^[A-Z]{3,}\s([^.]+)\.php [NC]
> RewriteRule ^ %1 [R,L]
> 
> RewriteRule ^([0-9a-zA-Z-_-]+)$ user.php?seller_user_name=$1
> 
> RewriteCond %{HTTP_HOST} !=localhost
> RewriteCond %{HTTP_HOST} !^www\.
> RewriteRule (.*) https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
> 
> #Now, rewrite to HTTPS if www present:
> RewriteCond %{HTTPS} off
> RewriteCond %{HTTP_HOST} !=localhost
> RewriteCond %{HTTP_HOST} ^www\.
> RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
> 
> Заранее благодарен.
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287900,287900#msg-287900
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 


From nginx-forum на forum.nginx.org  Thu Apr 30 07:51:41 2020
From: nginx-forum на forum.nginx.org (Luxerybelt)
Date: Thu, 30 Apr 2020 03:51:41 -0400
Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUg0LrQvtC90LLQtdGA0YLQuNGA0L7QstCw0YI=?=
 =?UTF-8?B?0YwgLmh0YWNjZXNzINCyINGE0LDQudC7IC5jb25mINC00LvRjyBuZ2lueC4=?=
In-Reply-To: <5e09826e-2dcd-bcdc-8185-3bfb95179ceb@ya.ru>
References: <5e09826e-2dcd-bcdc-8185-3bfb95179ceb@ya.ru>
Message-ID: <d32a8ab10166db8acd775ac6bb04a629.NginxMailingListRussian@forum.nginx.org>

Спасибо, но это только часть. А как трактовать это:

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} (.+)/$
RewriteRule ^ %1 [R=301,L]

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}\.php -f
RewriteRule ^(.*)$ $1.php

RewriteCond %{THE_REQUEST} ^[A-Z]{3,}\s([^.]+)\.php [NC]
RewriteRule ^ %1 [R,L]

RewriteRule ^([0-9a-zA-Z-_-]+)$ user.php?seller_user_name=$1

?

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


From nginx-forum на forum.nginx.org  Thu Apr 30 10:47:04 2020
From: nginx-forum на forum.nginx.org (gewisser)
Date: Thu, 30 Apr 2020 06:47:04 -0400
Subject: =?UTF-8?Q?Re=3A_Windows_=D0=B8_upstream_php-cgi=2Eexe?=
In-Reply-To: <20200429185615.GV20357@mdounin.ru>
References: <20200429185615.GV20357@mdounin.ru>
Message-ID: <d42ff6b3929b9518ecce9b10398dfdbe.NginxMailingListRussian@forum.nginx.org>

>  Я об этом писал в самом первом ответе - в конфиге nginx'а
>  выключить keepalive с помощью директивы keepalive_timeout
>  (http://nginx.org/r/keepalive_timeout/ru).

Это не есть решение вопроса. Если выключу, то выключу для всех соединений.
Мне нужен работающий keepalive. 
Так же не подходит: "отдельный location для запросов, в которых
предполагается долгая обработка "в фоне", и
выключить там keepalive с помощью директивы keepalive_timeout". Ни фронт ни
бэк на этапе старта запроса никак не может определить будет ли долгая
обработка или нет. Это решается в процессе выполнения скрипта (как я уже
писал). Если бэк решает, что он должен поработать в фоне, то сливает все
данные во фронт и работает. Не может в данный момент бэк управлять
соединением... 

Под линуксом, я могу закрыть соединение отправив мессадж в FPM выполнив
метод "fastcgi_finish_request()". Дайте мне "такое же" под Windows, чтобы
проект мог хоть как-то одинаково работать и под этой ОС.

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


From sytar.alex на gmail.com  Thu Apr 30 11:40:41 2020
From: sytar.alex на gmail.com (Aleksandr Sytar)
Date: Thu, 30 Apr 2020 14:40:41 +0300
Subject: =?UTF-8?Q?Re=3A_Windows_=D0=B8_upstream_php-cgi=2Eexe?=
In-Reply-To: <d42ff6b3929b9518ecce9b10398dfdbe.NginxMailingListRussian@forum.nginx.org>
References: <20200429185615.GV20357@mdounin.ru>
 <d42ff6b3929b9518ecce9b10398dfdbe.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAKqRTSEzWoQtwkHpDZDkMt9rZSixBnwrBp3duh2QMc7vtdcRCQ@mail.gmail.com>

чт, 30 апр. 2020 г. в 13:47, gewisser <nginx-forum на forum.nginx.org>:

>
> Под линуксом, я могу закрыть соединение отправив мессадж в FPM выполнив
> метод "fastcgi_finish_request()". Дайте мне "такое же" под Windows, чтобы
> проект мог хоть как-то одинаково работать и под этой ОС.
>
>
Если уж страдать под виндой, то по полной! Докер уже давно завезли, а там
глядишь и линукс внутри есть.
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200430/1ffc54f5/attachment.htm>

From nginx-forum на forum.nginx.org  Thu Apr 30 13:17:26 2020
From: nginx-forum на forum.nginx.org (gewisser)
Date: Thu, 30 Apr 2020 09:17:26 -0400
Subject: =?UTF-8?Q?Re=3A_Windows_=D0=B8_upstream_php-cgi=2Eexe?=
In-Reply-To: <CAKqRTSEzWoQtwkHpDZDkMt9rZSixBnwrBp3duh2QMc7vtdcRCQ@mail.gmail.com>
References: <CAKqRTSEzWoQtwkHpDZDkMt9rZSixBnwrBp3duh2QMc7vtdcRCQ@mail.gmail.com>
Message-ID: <447c259af5e7ad9784a194789fec1c37.NginxMailingListRussian@forum.nginx.org>

> Если уж страдать под виндой, то по полной! Докер уже давно завезли, а там
> глядишь и линукс внутри есть.

Завезли и докер с линуксом, завезли
WSL(https://docs.microsoft.com/ru-ru/windows/wsl/install-win10), завезли
идущую в комплекте виртуальную машину, но иногда не завозят мозги
заказчикам. Хотя по чесноку, я был удивлен, что nginx не содержит в себе
функционал по управлению соединением... В принципе, считаю плёвое дело
пропустить "Connection: close" до браузера из php, и закрыть вопрос....

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