From nginx-forum на forum.nginx.org  Wed Jul  1 00:18:42 2020
From: nginx-forum на forum.nginx.org (AviatorCJ2)
Date: Tue, 30 Jun 2020 20:18:42 -0400
Subject: RTMP restream server
Message-ID: <5d7870ef5a3f7dde5f852ad56d2cf8fc.NginxMailingListRussian@forum.nginx.org>

Всем привет, поднял на nginx rtmp-сервер, задача которого брать с OBS
видео-поток и рестримить его сразу на несколько сервисов (ютуб, твич и
т.д.)
-------
worker_processes  1;
error_log  logs/error.log info;
events {
    worker_connections  1024;
}
rtmp {
        server {
                listen 1935;
                chunk_size 4096;
 
                application live {
                        live on;
                        record off;
                        push rtmp://youtube/live38uphbx7;
                        push rtmp://twich/live/l2xgvdwi;
--------
Всё отлично работает, но одновременно на этом же ПК запущено два OBS с
разным контентом, который нужно рестримить на разные сервисы. 
Вопрос, можно ли поднять на одном ПК два nginx сервера, для этой задачи. Или
на одном nginx запустить два rtmp-сервера. Или может есть мысли как
по-другому сделать такой рестрим. 
Буду благодарен за любые идеи. Спасибо ;)

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


From rogat1y на gmail.com  Wed Jul  1 20:58:03 2020
From: rogat1y на gmail.com (Maxim K)
Date: Wed, 1 Jul 2020 23:58:03 +0300
Subject: RTMP restream server
In-Reply-To: <5d7870ef5a3f7dde5f852ad56d2cf8fc.NginxMailingListRussian@forum.nginx.org>
References: <5d7870ef5a3f7dde5f852ad56d2cf8fc.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAB-_x2NgBFnboOUrS7Ltbno6uELDSf8otAhodPqFKHt+3rZbDQ@mail.gmail.com>

Сделайте еще один application, который будет делать push на другие адреса.

ср, 1 июл. 2020 г. в 03:18, AviatorCJ2 <nginx-forum на forum.nginx.org>:

> Всем привет, поднял на nginx rtmp-сервер, задача которого брать с OBS
> видео-поток и рестримить его сразу на несколько сервисов (ютуб, твич и
> т.д.)
> -------
> worker_processes  1;
> error_log  logs/error.log info;
> events {
>     worker_connections  1024;
> }
> rtmp {
>         server {
>                 listen 1935;
>                 chunk_size 4096;
>
>                 application live {
>                         live on;
>                         record off;
>                         push rtmp://youtube/live38uphbx7;
>                         push rtmp://twich/live/l2xgvdwi;
> --------
> Всё отлично работает, но одновременно на этом же ПК запущено два OBS с
> разным контентом, который нужно рестримить на разные сервисы.
> Вопрос, можно ли поднять на одном ПК два nginx сервера, для этой задачи.
> Или
> на одном nginx запустить два rtmp-сервера. Или может есть мысли как
> по-другому сделать такой рестрим.
> Буду благодарен за любые идеи. Спасибо ;)
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288508,288508#msg-288508
>
> _______________________________________________
> 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/20200701/49178ab4/attachment.htm>

From nginx-forum на forum.nginx.org  Wed Jul  1 21:58:56 2020
From: nginx-forum на forum.nginx.org (AviatorCJ2)
Date: Wed, 01 Jul 2020 17:58:56 -0400
Subject: RTMP restream server
In-Reply-To: <CAB-_x2NgBFnboOUrS7Ltbno6uELDSf8otAhodPqFKHt+3rZbDQ@mail.gmail.com>
References: <CAB-_x2NgBFnboOUrS7Ltbno6uELDSf8otAhodPqFKHt+3rZbDQ@mail.gmail.com>
Message-ID: <5f60ac7d3e12711a29790a35687ed48e.NginxMailingListRussian@forum.nginx.org>

Но ведь этот второй application будет брать видео-поток с того же OBS, а нам
нужно со второго, или второй application будет уже не на localhost?

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


From nginx-forum на forum.nginx.org  Wed Jul  1 23:54:20 2020
From: nginx-forum на forum.nginx.org (AviatorCJ2)
Date: Wed, 01 Jul 2020 19:54:20 -0400
Subject: RTMP restream server
In-Reply-To: <CAB-_x2NgBFnboOUrS7Ltbno6uELDSf8otAhodPqFKHt+3rZbDQ@mail.gmail.com>
References: <CAB-_x2NgBFnboOUrS7Ltbno6uELDSf8otAhodPqFKHt+3rZbDQ@mail.gmail.com>
Message-ID: <283e9214b5bded83ab38e981d3f59727.NginxMailingListRussian@forum.nginx.org>

Я из obs стримлю на rtmp://localhost/live, а на nginx «размножаю» этот стрим
на несколько других rtmp серверов. А на втором obs, с другим контентом
который тоже надо «размножить» если я укажу тот же rtmp://localhost/live то
как он поймет что для него предназначаются уже другие пуши? Или live это
есть название первого application и второй можно назвать например live2 и он
будет по ссылке rtmp://localhost/live2? Сорри если я задаю тупые вопросы но
я второй 3ий день пользуюсь nginx и ещё не особо разбираюсь. Но в любом
случае спасибо за помощь)

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


From rogat1y на gmail.com  Thu Jul  2 09:08:29 2020
From: rogat1y на gmail.com (Maxim K)
Date: Thu, 2 Jul 2020 12:08:29 +0300
Subject: RTMP restream server
In-Reply-To: <283e9214b5bded83ab38e981d3f59727.NginxMailingListRussian@forum.nginx.org>
References: <CAB-_x2NgBFnboOUrS7Ltbno6uELDSf8otAhodPqFKHt+3rZbDQ@mail.gmail.com>
 <283e9214b5bded83ab38e981d3f59727.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAB-_x2O0zdTWQtRH0dxgq_31yguTae1_BpWJvVmyQRArVM+a5g@mail.gmail.com>

> Или live это есть название первого application и второй можно назвать
например live2 и он будет по ссылке rtmp://localhost/live2
да

чт, 2 июл. 2020 г. в 02:54, AviatorCJ2 <nginx-forum на forum.nginx.org>:

> Я из obs стримлю на rtmp://localhost/live, а на nginx «размножаю» этот
> стрим
> на несколько других rtmp серверов. А на втором obs, с другим контентом
> который тоже надо «размножить» если я укажу тот же rtmp://localhost/live то
> как он поймет что для него предназначаются уже другие пуши? Или live это
> есть название первого application и второй можно назвать например live2 и
> он
> будет по ссылке rtmp://localhost/live2? Сорри если я задаю тупые вопросы но
> я второй 3ий день пользуюсь nginx и ещё не особо разбираюсь. Но в любом
> случае спасибо за помощь)
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288508,288519#msg-288519
>
> _______________________________________________
> 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/20200702/58d0893d/attachment.htm>

From nginx-forum на forum.nginx.org  Fri Jul  3 19:51:19 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Fri, 03 Jul 2020 15:51:19 -0400
Subject: =?UTF-8?B?0JrQsNC6INC90LAgaHR0cHMt0YHQtdGA0LLQtdGA0LUg0LTQsNGC0Ywg0LTQvtGB?=
 =?UTF-8?B?0YLRg9C/INC6INC+0L/RgNC10LTQtdC70LXQvdC90L7QvNGDINC/0YPRgtC4?=
 =?UTF-8?B?INC/0L4gaHR0cC3Qv9GA0L7RgtC+0LrQvtC70YM/?=
Message-ID: <be089d16af7b4e490bcc0f0c51eacec2.NginxMailingListRussian@forum.nginx.org>

Приветствую...
У меня nginx (https)+passenger.
https://server-name.com/contacts - все страницы работают на https.
http://server-name.com/upload/folder1/img/img_b.jpg - но если захожу по http
и в URI встречаеться /upload/, то отдавать по http...
Как правильно реализовать?

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


From pnz.stalker на mail.ru  Fri Jul  3 20:39:34 2020
From: pnz.stalker на mail.ru (=?UTF-8?B?0JDQvdGC0L7QvSDQk9C+0YDQu9C+0LI=?=)
Date: Fri, 3 Jul 2020 23:39:34 +0300
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvdCwIGh0dHBzLdGB0LXRgNCy0LXRgNC1INC00LDRgtGMINC0?=
 =?UTF-8?B?0L7RgdGC0YPQvyDQuiDQvtC/0YDQtdC00LXQu9C10L3QvdC+0LzRgyDQv9GD?=
 =?UTF-8?B?0YLQuCDQv9C+IGh0dHAt0L/RgNC+0YLQvtC60L7Qu9GDPw==?=
In-Reply-To: <be089d16af7b4e490bcc0f0c51eacec2.NginxMailingListRussian@forum.nginx.org>
References: <be089d16af7b4e490bcc0f0c51eacec2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <6be519b4-e1bb-d0cd-dbce-7460f1e0d48c@mail.ru>

03.07.2020 22:51, akoval пишет:
> Приветствую...
> У меня nginx (https)+passenger.
> https://server-name.com/contacts - все страницы работают на https.
> http://server-name.com/upload/folder1/img/img_b.jpg - но если захожу по http
> и в URI встречаеться /upload/, то отдавать по http...
> Как правильно реализовать?

nginx в общем-то всё равно как отдавать.а вот браузеры такое не скушают.
https://developer.mozilla.org/ru/docs/Security/MixedContent

From matorola на gmail.com  Fri Jul  3 21:55:13 2020
From: matorola на gmail.com (Anatoly Pugachev)
Date: Sat, 4 Jul 2020 00:55:13 +0300
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvdCwIGh0dHBzLdGB0LXRgNCy0LXRgNC1INC00LDRgtGMINC0?=
 =?UTF-8?B?0L7RgdGC0YPQvyDQuiDQvtC/0YDQtdC00LXQu9C10L3QvdC+0LzRgyDQv9GD?=
 =?UTF-8?B?0YLQuCDQv9C+IGh0dHAt0L/RgNC+0YLQvtC60L7Qu9GDPw==?=
In-Reply-To: <6be519b4-e1bb-d0cd-dbce-7460f1e0d48c@mail.ru>
References: <be089d16af7b4e490bcc0f0c51eacec2.NginxMailingListRussian@forum.nginx.org>
 <6be519b4-e1bb-d0cd-dbce-7460f1e0d48c@mail.ru>
Message-ID: <CADxRZqxyk2N1gSV4FJ3o+xS7VadaQwWTdmpBbHuaE1o_V5zAaA@mail.gmail.com>

On Fri, Jul 3, 2020 at 11:44 PM Антон Горлов <pnz.stalker на mail.ru> wrote:
> 03.07.2020 22:51, akoval пишет:
> > Приветствую...
> > У меня nginx (https)+passenger.
> > https://server-name.com/contacts - все страницы работают на https.
> > http://server-name.com/upload/folder1/img/img_b.jpg - но если захожу по http
> > и в URI встречаеться /upload/, то отдавать по http...
> > Как правильно реализовать?
>
> nginx в общем-то всё равно как отдавать.а вот браузеры такое не скушают.
> https://developer.mozilla.org/ru/docs/Security/MixedContent

так то да, но можно попробовать на том же nginx сделать еще один vhost
но уже с http, а в оригинальном location отдавать 30x (301, 302) код
на новое место.

From nginx-forum на forum.nginx.org  Sat Jul  4 01:49:21 2020
From: nginx-forum на forum.nginx.org (AviatorCJ2)
Date: Fri, 03 Jul 2020 21:49:21 -0400
Subject: RTMP restream server
In-Reply-To: <CAB-_x2O0zdTWQtRH0dxgq_31yguTae1_BpWJvVmyQRArVM+a5g@mail.gmail.com>
References: <CAB-_x2O0zdTWQtRH0dxgq_31yguTae1_BpWJvVmyQRArVM+a5g@mail.gmail.com>
Message-ID: <3aa3489f8ae2124afb07131f850326e6.NginxMailingListRussian@forum.nginx.org>

Работает, большое спасибо.
Но есть ещё один маленький вопрос.
Когда всё запущено и работает, иногда в nginx.conf нужно поменять ссылки у
пушей или добавить новых, например
--- было так:
push rtmp://youtube/live38uphbx7;
--- а сделать так:
push rtmp://youtube/live38uphbx7;
push rtmp://twich/live/l2xgvdwi
---
Для этого можно отредактировать conf, остановить сервер, запустить сервер -
и начнётся стрим на 2 сервиса, вместо одного. Но на первом сервисе стрим
прервётся на то время, пока сервер перезапускается.
Могу ли я для этой операции использовать след. команду (чтобы стрим не
прерывался)?
---
nginx.exe -s reload
---
Я просто пробовал, ничего не происходит, отредактированный nginx.conf не
задействуется а в статистике "http://localhost:8080/stat" всё пропадает.
Также в диспетчере задач появляется ещё один процесс, третий.

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


From red-fox0 на ya.ru  Sat Jul  4 04:12:13 2020
From: red-fox0 на ya.ru (fox)
Date: Sat, 4 Jul 2020 11:12:13 +0700
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQvdCwIGh0dHBzLdGB0LXRgNCy0LXRgNC1INC00LDRgtGMINC0?=
 =?UTF-8?B?0L7RgdGC0YPQvyDQuiDQvtC/0YDQtdC00LXQu9C10L3QvdC+0LzRgyDQv9GD?=
 =?UTF-8?B?0YLQuCDQv9C+IGh0dHAt0L/RgNC+0YLQvtC60L7Qu9GDPw==?=
In-Reply-To: <be089d16af7b4e490bcc0f0c51eacec2.NginxMailingListRussian@forum.nginx.org>
References: <be089d16af7b4e490bcc0f0c51eacec2.NginxMailingListRussian@forum.nginx.org>
Message-ID: <25c5000d-c2e7-8b1a-48da-a485e7ff17d7@ya.ru>

server {
  listen 80;
  server_name server-name.com;

  location / {
    return 301 https://$host$request_uri;
  }

  location /upload/ {
    try_files $uri $uri/ =404;
  }
}

server {
  listen 443;
  #...
}


04.07.2020 02:51, akoval пишет:
> Приветствую...
> У меня nginx (https)+passenger.
> https://server-name.com/contacts - все страницы работают на https.
> http://server-name.com/upload/folder1/img/img_b.jpg - но если захожу по http
> и в URI встречаеться /upload/, то отдавать по http...
> Как правильно реализовать?
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288545,288545#msg-288545
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 


From rogat1y на gmail.com  Sat Jul  4 09:29:35 2020
From: rogat1y на gmail.com (Maxim K)
Date: Sat, 4 Jul 2020 12:29:35 +0300
Subject: RTMP restream server
In-Reply-To: <3aa3489f8ae2124afb07131f850326e6.NginxMailingListRussian@forum.nginx.org>
References: <CAB-_x2O0zdTWQtRH0dxgq_31yguTae1_BpWJvVmyQRArVM+a5g@mail.gmail.com>
 <3aa3489f8ae2124afb07131f850326e6.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAB-_x2O33Qqw00Ve1S27aEF2LabJE7Am0UEs13-FFgXhbTNPMw@mail.gmail.com>

rtmp модуль не поддерживает reload
https://github.com/arut/nginx-rtmp-module/issues/1328#issuecomment-435502803

сб, 4 июл. 2020 г. в 04:49, AviatorCJ2 <nginx-forum на forum.nginx.org>:

> Работает, большое спасибо.
> Но есть ещё один маленький вопрос.
> Когда всё запущено и работает, иногда в nginx.conf нужно поменять ссылки у
> пушей или добавить новых, например
> --- было так:
> push rtmp://youtube/live38uphbx7;
> --- а сделать так:
> push rtmp://youtube/live38uphbx7;
> push rtmp://twich/live/l2xgvdwi
> ---
> Для этого можно отредактировать conf, остановить сервер, запустить сервер -
> и начнётся стрим на 2 сервиса, вместо одного. Но на первом сервисе стрим
> прервётся на то время, пока сервер перезапускается.
> Могу ли я для этой операции использовать след. команду (чтобы стрим не
> прерывался)?
> ---
> nginx.exe -s reload
> ---
> Я просто пробовал, ничего не происходит, отредактированный nginx.conf не
> задействуется а в статистике "http://localhost:8080/stat" всё пропадает.
> Также в диспетчере задач появляется ещё один процесс, третий.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288508,288548#msg-288548
>
> _______________________________________________
> 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/20200704/170a9070/attachment-0001.htm>

From nginx-forum на forum.nginx.org  Sat Jul  4 09:51:34 2020
From: nginx-forum на forum.nginx.org (AviatorCJ2)
Date: Sat, 04 Jul 2020 05:51:34 -0400
Subject: RTMP restream server
In-Reply-To: <CAB-_x2O33Qqw00Ve1S27aEF2LabJE7Am0UEs13-FFgXhbTNPMw@mail.gmail.com>
References: <CAB-_x2O33Qqw00Ve1S27aEF2LabJE7Am0UEs13-FFgXhbTNPMw@mail.gmail.com>
Message-ID: <7e93f8032382f971f17d704d6eeb4c2e.NginxMailingListRussian@forum.nginx.org>

Печально. Ну ладно. Спасибо за помощь

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


From gmm на csdoc.com  Sat Jul  4 17:53:57 2020
From: gmm на csdoc.com (Gena Makhomed)
Date: Sat, 4 Jul 2020 20:53:57 +0300
Subject: ssl_protocols
In-Reply-To: <20200629140756.GZ12747@mdounin.ru>
References: <e9bd39ba-6fa8-e788-8ad4-fc049d70b181@csdoc.com>
 <20200625192707.GT12747@mdounin.ru>
 <da82db37-6777-ffb7-d483-f2fa3b2fdf72@csdoc.com>
 <20200629140756.GZ12747@mdounin.ru>
Message-ID: <78b46597-2110-2cad-6252-8cb2c3d8ac60@csdoc.com>

On 29.06.2020 17:07, Maxim Dounin wrote:

 > Соответственно для включения TLSv1.3 по умолчанию надо решить две
 > проблемы:
 >
 > 1. Сделать решение, которое бы позволило реализовать ту же
 > семантику "отазаться общаться, не предъявляя сертификата" в
 > условиях наличия TLSv1.3.
 >
 > 2. Придумать решение для существующих конфигураций с "ssl_ciphers
 > aNULL; return 444;".

Эти две проблемы выглядят как в принципе не решаемые
в условиях наличия включенного протокола TLSv1.3.


>>> в TLSv1.3 не настраиваются шифры
>>
>> И если быть уж совсем точным, шифры в TLSv1.3 настраиваются.
>> Точнее в OpenSSL шифры для TLSv1.3 можно настроить. Проблема
>> только в том, что вот разработчики nginx не могут договориться
>> с разработчиками OpenSSL о том, как эти шифры необходимо настраивать.
>>
>> В том же Apache можно без проблем настроить шифры для TLSv1.3:
>> https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite
>>
>> Если никак не получается договориться с разработчиками OpenSSL,
>> может быть имеет сделать смысл форк OpenSSL иил написать с нуля
>> свою собственную библиотеку? Ведь когда-то так и nginx появился,
>> когда стало понятно, что apache не подходит для некоторых задач.
>>
>> Или пойти по пути Apache, сделав возможность раздельной настройки
>> шифров для TLSv1.2 и для TLSv1.3 ? Ведь по прошествии такого количества
>> времени уже стало понятно, что разработчики OpenSSL свою точку зрения
>> по этому вопросу менять не собираются и в OpenSSL все будет так же.
> 
> В тикете тут:
> 
> https://trac.nginx.org/nginx/ticket/1529
> 
> и связанных тикетах - достаточно подробно расписано, что
> настраивается, что не настраивается (в BoringSSL, например, для
> TLSv1.3 не настраивается вообще ничего), и что именно я думаю по
> этому поводу.  Не вижу смысла тут повторяться.

Два года назад Вы написали:

https://trac.nginx.org/nginx/ticket/1529#comment:1

"I don't think that nginx should add support for this interface
before the long-term approach is clear".

https://trac.nginx.org/nginx/ticket/1529#comment:4

For now, solution to configure ciphers as implemented
in OpenSSL 1.1.1-dev looks highly inconsistent, and it is not clear
what they are going to do next. Once there will be a clear
and consistent long-term approach available, we'll consider
what to do with this.

Теперь, по прошествии двух лет - long-term approach is clear.

В OpenSSL ничего не изменится, хотя бы потому,
что поддержка нового интерфейса уже встроена в httpd Apache.

-- 
Best regards,
  Gena


From chipitsine на gmail.com  Sat Jul  4 19:50:45 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sun, 5 Jul 2020 00:50:45 +0500
Subject: ssl_protocols
In-Reply-To: <78b46597-2110-2cad-6252-8cb2c3d8ac60@csdoc.com>
References: <e9bd39ba-6fa8-e788-8ad4-fc049d70b181@csdoc.com>
 <20200625192707.GT12747@mdounin.ru>
 <da82db37-6777-ffb7-d483-f2fa3b2fdf72@csdoc.com>
 <20200629140756.GZ12747@mdounin.ru>
 <78b46597-2110-2cad-6252-8cb2c3d8ac60@csdoc.com>
Message-ID: <CAFHpkQHUVEmOfq2nLdZ2gxWvuiM4SE-E=_ZhqOwM_bq+r88S+g@mail.gmail.com>

сб, 4 июл. 2020 г. в 22:54, Gena Makhomed <gmm на csdoc.com>:

> On 29.06.2020 17:07, Maxim Dounin wrote:
>
>  > Соответственно для включения TLSv1.3 по умолчанию надо решить две
>  > проблемы:
>


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


>  >
>  > 1. Сделать решение, которое бы позволило реализовать ту же
>  > семантику "отазаться общаться, не предъявляя сертификата" в
>  > условиях наличия TLSv1.3.
>  >
>  > 2. Придумать решение для существующих конфигураций с "ssl_ciphers
>  > aNULL; return 444;".
>
> Эти две проблемы выглядят как в принципе не решаемые
> в условиях наличия включенного протокола TLSv1.3.
>
>
> >>> в TLSv1.3 не настраиваются шифры
> >>
> >> И если быть уж совсем точным, шифры в TLSv1.3 настраиваются.
> >> Точнее в OpenSSL шифры для TLSv1.3 можно настроить. Проблема
> >> только в том, что вот разработчики nginx не могут договориться
> >> с разработчиками OpenSSL о том, как эти шифры необходимо настраивать.
> >>
> >> В том же Apache можно без проблем настроить шифры для TLSv1.3:
> >> https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite
> >>
> >> Если никак не получается договориться с разработчиками OpenSSL,
> >> может быть имеет сделать смысл форк OpenSSL иил написать с нуля
> >> свою собственную библиотеку? Ведь когда-то так и nginx появился,
> >> когда стало понятно, что apache не подходит для некоторых задач.
> >>
> >> Или пойти по пути Apache, сделав возможность раздельной настройки
> >> шифров для TLSv1.2 и для TLSv1.3 ? Ведь по прошествии такого количества
> >> времени уже стало понятно, что разработчики OpenSSL свою точку зрения
> >> по этому вопросу менять не собираются и в OpenSSL все будет так же.
> >
> > В тикете тут:
> >
> > https://trac.nginx.org/nginx/ticket/1529
> >
> > и связанных тикетах - достаточно подробно расписано, что
> > настраивается, что не настраивается (в BoringSSL, например, для
> > TLSv1.3 не настраивается вообще ничего), и что именно я думаю по
> > этому поводу.  Не вижу смысла тут повторяться.
>
> Два года назад Вы написали:
>
> https://trac.nginx.org/nginx/ticket/1529#comment:1
>
> "I don't think that nginx should add support for this interface
> before the long-term approach is clear".
>
> https://trac.nginx.org/nginx/ticket/1529#comment:4
>
> For now, solution to configure ciphers as implemented
> in OpenSSL 1.1.1-dev looks highly inconsistent, and it is not clear
> what they are going to do next. Once there will be a clear
> and consistent long-term approach available, we'll consider
> what to do with this.
>
> Теперь, по прошествии двух лет - long-term approach is clear.
>
> В OpenSSL ничего не изменится, хотя бы потому,
> что поддержка нового интерфейса уже встроена в httpd Apache.
>
> --
> Best regards,
>   Gena
>
> _______________________________________________
> 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/20200705/b6e22e36/attachment.htm>

From mdounin на mdounin.ru  Mon Jul  6 19:17:25 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 6 Jul 2020 22:17:25 +0300
Subject: ssl_protocols
In-Reply-To: <78b46597-2110-2cad-6252-8cb2c3d8ac60@csdoc.com>
References: <e9bd39ba-6fa8-e788-8ad4-fc049d70b181@csdoc.com>
 <20200625192707.GT12747@mdounin.ru>
 <da82db37-6777-ffb7-d483-f2fa3b2fdf72@csdoc.com>
 <20200629140756.GZ12747@mdounin.ru>
 <78b46597-2110-2cad-6252-8cb2c3d8ac60@csdoc.com>
Message-ID: <20200706191725.GF12747@mdounin.ru>

Hello!

On Sat, Jul 04, 2020 at 08:53:57PM +0300, Gena Makhomed wrote:

> On 29.06.2020 17:07, Maxim Dounin wrote:
> 
> > Соответственно для включения TLSv1.3 по умолчанию надо решить две
> > проблемы:
> >
> > 1. Сделать решение, которое бы позволило реализовать ту же
> > семантику "отазаться общаться, не предъявляя сертификата" в
> > условиях наличия TLSv1.3.
> >
> > 2. Придумать решение для существующих конфигураций с "ssl_ciphers
> > aNULL; return 444;".
> 
> Эти две проблемы выглядят как в принципе не решаемые
> в условиях наличия включенного протокола TLSv1.3.

Как минимум первая из этих проблем легко решается возвратом ошибки 
из ngx_http_ssl_servername().  Основной вопрос - что делать со 
второй.  И вот тут не совсем понятно, существует ли хорошее 
решение, внешнее по отношению к SSL-библиотеке.

> > > > в TLSv1.3 не настраиваются шифры
> > > 
> > > И если быть уж совсем точным, шифры в TLSv1.3 настраиваются.
> > > Точнее в OpenSSL шифры для TLSv1.3 можно настроить. Проблема
> > > только в том, что вот разработчики nginx не могут договориться
> > > с разработчиками OpenSSL о том, как эти шифры необходимо настраивать.
> > > 
> > > В том же Apache можно без проблем настроить шифры для TLSv1.3:
> > > https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslciphersuite
> > > 
> > > Если никак не получается договориться с разработчиками OpenSSL,
> > > может быть имеет сделать смысл форк OpenSSL иил написать с нуля
> > > свою собственную библиотеку? Ведь когда-то так и nginx появился,
> > > когда стало понятно, что apache не подходит для некоторых задач.
> > > 
> > > Или пойти по пути Apache, сделав возможность раздельной настройки
> > > шифров для TLSv1.2 и для TLSv1.3 ? Ведь по прошествии такого количества
> > > времени уже стало понятно, что разработчики OpenSSL свою точку зрения
> > > по этому вопросу менять не собираются и в OpenSSL все будет так же.
> > 
> > В тикете тут:
> > 
> > https://trac.nginx.org/nginx/ticket/1529
> > 
> > и связанных тикетах - достаточно подробно расписано, что
> > настраивается, что не настраивается (в BoringSSL, например, для
> > TLSv1.3 не настраивается вообще ничего), и что именно я думаю по
> > этому поводу.  Не вижу смысла тут повторяться.
> 
> Два года назад Вы написали:
> 
> https://trac.nginx.org/nginx/ticket/1529#comment:1
> 
> "I don't think that nginx should add support for this interface
> before the long-term approach is clear".
> 
> https://trac.nginx.org/nginx/ticket/1529#comment:4
> 
> For now, solution to configure ciphers as implemented
> in OpenSSL 1.1.1-dev looks highly inconsistent, and it is not clear
> what they are going to do next. Once there will be a clear
> and consistent long-term approach available, we'll consider
> what to do with this.
> 
> Теперь, по прошествии двух лет - long-term approach is clear.

Ну вообще говоря нет, проблему "openssl ciphers" в OpenSSL так и 
не решили.

Ну и с тем же успехом long-term approach is clear в BoringSSL, где 
шифры для TLSv1.3 вообще не настраиваются.

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

https://trac.nginx.org/nginx/ticket/1529#comment:11

Однако это не то чтобы поможет в решении задачи "включить TLSv1.3 
по умолчанию", потому что обеспечить адекватную работу 
"ssl_ciphers aNULL;" внешняя прослойка не очень поможет.  Разве 
что пытаться узнавать в лицо конкретную строку aNULL, но от этого 
решения очень уж сильно пахнет хаком.

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

From mdounin на mdounin.ru  Tue Jul  7 16:11:15 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 7 Jul 2020 19:11:15 +0300
Subject: nginx-1.19.1
Message-ID: <20200707161115.GP12747@mdounin.ru>

Изменения в nginx 1.19.1                                          07.07.2020

    *) Изменение: директивы lingering_close, lingering_time и
       lingering_timeout теперь работают при использовании HTTP/2.

    *) Изменение: теперь лишние данные, присланные бэкендом, всегда
       отбрасываются.

    *) Изменение: теперь при получении слишком короткого ответа от
       FastCGI-сервера nginx пытается отправить клиенту доступную часть
       ответа, после чего закрывает соединение с клиентом.

    *) Изменение: теперь при получении ответа некорректной длины от
       gRPC-бэкенда nginx прекращает обработку ответа с ошибкой.

    *) Добавление: параметр min_free в директивах proxy_cache_path,
       fastcgi_cache_path, scgi_cache_path и uwsgi_cache_path.
       Спасибо Adam Bambuch.

    *) Исправление: nginx не удалял unix domain listen-сокеты при плавном
       завершении по сигналу SIGQUIT.

    *) Исправление: UDP-пакеты нулевого размера не проксировались.

    *) Исправление: проксирование на uwsgi-бэкенды с использованием SSL
       могло не работать.
       Спасибо Guanzhong Chen.

    *) Исправление: в обработке ошибок при использовании директивы ssl_ocsp.

    *) Исправление: при использовании файловых систем XFS и NFS размер кэша
       на диске мог считаться некорректно.

    *) Исправление: если сервер memcached возвращал некорректный ответ, в
       логах могли появляться сообщения "negative size buf in writer".


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

From raven_kg на megaline.kg  Thu Jul  9 05:43:17 2020
From: raven_kg на megaline.kg (raven_kg на megaline.kg)
Date: Thu, 9 Jul 2020 11:43:17 +0600
Subject: =?UTF-8?B?0JjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LUg0L/QtdGA0LXQvNC10L3QvdGL0YUg?=
 =?UTF-8?B?0LIgcHJveHlfY2FjaGVfdmFsaWQ=?=
Message-ID: <11a65700-238f-4c13-d48f-aa9e529fd34d@megaline.kg>

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

Возникла необходимость задавать разное время кэширования для некоторых 
IP, возможно-ли это реализовать в nginx не дробя в разные локейшены?

В соотв. с документацией, proxy_cache_valid не может быть использована 
внутри if, конструкция типа:

    geo $cache_time {

         default 1m;

          192.168.0.12 10s;

    }

    ...

    proxy_cache_valid 200 301 $cache_time;


тоже не сработала:

    nginx: [emerg] invalid time value "$cache_time"

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

From mdounin на mdounin.ru  Thu Jul  9 13:02:51 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 9 Jul 2020 16:02:51 +0300
Subject: =?UTF-8?B?UmU6INCY0YHQv9C+0LvRjNC30L7QstCw0L3QuNC1INC/0LXRgNC10LzQtdC90L0=?=
 =?UTF-8?B?0YvRhSDQsiBwcm94eV9jYWNoZV92YWxpZA==?=
In-Reply-To: <11a65700-238f-4c13-d48f-aa9e529fd34d@megaline.kg>
References: <11a65700-238f-4c13-d48f-aa9e529fd34d@megaline.kg>
Message-ID: <20200709130251.GR12747@mdounin.ru>

Hello!

On Thu, Jul 09, 2020 at 11:43:17AM +0600, raven_kg на megaline.kg wrote:

> Возникла необходимость задавать разное время кэширования для 
> некоторых IP, возможно-ли это реализовать в nginx не дробя в 
> разные локейшены?

Нет.

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

From nginx-forum на forum.nginx.org  Thu Jul  9 13:38:13 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Thu, 09 Jul 2020 09:38:13 -0400
Subject: =?UTF-8?B?U1NMINC00LvRjyBJRSA4?=
Message-ID: <f3f28d3c39d64c2b39d4b6d91ef1bb5b.NginxMailingListRussian@forum.nginx.org>

Привет всем!

Возникла задача сделать, чтобы сайт открывался в Windows XP на IE 8. На
сайте
https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=nginx-1.10.3&openssl=1.0.1e&hsts=yes&profile=old
выбрал - создать конфиг под старые браузеры, получил набор шифров:

ssl_ciphers
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA;

Если верить интернету, то для работы сайта в IE 8 необходим последний в
списке "DES-CBC3-SHA", но почему сайт не открывается. Нашел в инете патч для
IE 8, который добавляет 256 битное шифрование для этого старого браузера и
он помог, но это не вариант. 

Подскажите, что не хватает в конфиге, чтобы сайт открывался в этом браузере?

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


From chipitsine на gmail.com  Thu Jul  9 14:25:21 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 9 Jul 2020 19:25:21 +0500
Subject: =?UTF-8?B?UmU6IFNTTCDQtNC70Y8gSUUgOA==?=
In-Reply-To: <f3f28d3c39d64c2b39d4b6d91ef1bb5b.NginxMailingListRussian@forum.nginx.org>
References: <f3f28d3c39d64c2b39d4b6d91ef1bb5b.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQFRqVdWCLSdncL47b+-6D3Ys+TYNNAQMQ76DZEUgjAUaw@mail.gmail.com>

чт, 9 июл. 2020 г. в 18:38, grey <nginx-forum на forum.nginx.org>:

> Привет всем!
>
> Возникла задача сделать, чтобы сайт открывался в Windows XP на IE 8. На
> сайте
>
> https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=nginx-1.10.3&openssl=1.0.1e&hsts=yes&profile=old
> выбрал - создать конфиг под старые браузеры, получил набор шифров:
>
> ssl_ciphers
>
> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA;
>
> Если верить интернету, то для работы сайта в IE 8 необходим последний в
> списке "DES-CBC3-SHA", но почему сайт не открывается. Нашел в инете патч
> для
> IE 8, который добавляет 256 битное шифрование для этого старого браузера и
> он помог, но это не вариант.
>

256-битное шифрование это SHA2 ?
дело в том, что до WinXP SP2 поддерживался только SHA1
начиная с SP2 поддерживается SHA2

сертификат сейчас вы можете выпустить только SHA2



>
> Подскажите, что не хватает в конфиге, чтобы сайт открывался в этом
> браузере?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288640,288640#msg-288640
>
> _______________________________________________
> 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/20200709/cfbf8e7d/attachment.htm>

From nginx-forum на forum.nginx.org  Thu Jul  9 14:40:48 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Thu, 09 Jul 2020 10:40:48 -0400
Subject: =?UTF-8?B?UmU6IFNTTCDQtNC70Y8gSUUgOA==?=
In-Reply-To: <CAFHpkQFRqVdWCLSdncL47b+-6D3Ys+TYNNAQMQ76DZEUgjAUaw@mail.gmail.com>
References: <CAFHpkQFRqVdWCLSdncL47b+-6D3Ys+TYNNAQMQ76DZEUgjAUaw@mail.gmail.com>
Message-ID: <f88a7daca94f5823c2e3980e963ef020.NginxMailingListRussian@forum.nginx.org>

Да, вроде бы SHA-2 - это 256 бит. У меня WinXP SP3 со всем обновлениями.
Официально IE 8 поддерживает только 128 битное шифрование. Вот я и пытаюсь
запустить на нем сайт. Перепробовал уже несколько вариантов из интернета с
разными наборами шифров - не открывается сайт в этом браузере.

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


From nginx-forum на forum.nginx.org  Thu Jul  9 14:48:34 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Thu, 09 Jul 2020 10:48:34 -0400
Subject: =?UTF-8?B?UmU6IFNTTCDQtNC70Y8gSUUgOA==?=
In-Reply-To: <f88a7daca94f5823c2e3980e963ef020.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQFRqVdWCLSdncL47b+-6D3Ys+TYNNAQMQ76DZEUgjAUaw@mail.gmail.com>
 <f88a7daca94f5823c2e3980e963ef020.NginxMailingListRussian@forum.nginx.org>
Message-ID: <893827fb26d8036fb90c5b85b093b0ad.NginxMailingListRussian@forum.nginx.org>

Да, наверно нашел причину. Сертификат у меня выпущен Let’s Encrypt, а он не
поддерживает старые шифры.

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


From chipitsine на gmail.com  Thu Jul  9 20:20:15 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 10 Jul 2020 01:20:15 +0500
Subject: =?UTF-8?B?UmU6IFNTTCDQtNC70Y8gSUUgOA==?=
In-Reply-To: <f88a7daca94f5823c2e3980e963ef020.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQFRqVdWCLSdncL47b+-6D3Ys+TYNNAQMQ76DZEUgjAUaw@mail.gmail.com>
 <f88a7daca94f5823c2e3980e963ef020.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQG8nzwyFE7te0mQe4TdZvPd0BMVR9i9bYR_MneVPWnrOw@mail.gmail.com>

очень правдоподобную картинку по client handshake дает SSL Labs
попробуйте?

чт, 9 июл. 2020 г. в 19:40, grey <nginx-forum на forum.nginx.org>:

> Да, вроде бы SHA-2 - это 256 бит. У меня WinXP SP3 со всем обновлениями.
> Официально IE 8 поддерживает только 128 битное шифрование. Вот я и пытаюсь
> запустить на нем сайт. Перепробовал уже несколько вариантов из интернета с
> разными наборами шифров - не открывается сайт в этом браузере.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288640,288644#msg-288644
>
> _______________________________________________
> 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/20200710/05881203/attachment-0001.htm>

From nginx-forum на forum.nginx.org  Fri Jul 10 09:23:04 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Fri, 10 Jul 2020 05:23:04 -0400
Subject: =?UTF-8?B?UmU6IFNTTCDQtNC70Y8gSUUgOA==?=
In-Reply-To: <CAFHpkQG8nzwyFE7te0mQe4TdZvPd0BMVR9i9bYR_MneVPWnrOw@mail.gmail.com>
References: <CAFHpkQG8nzwyFE7te0mQe4TdZvPd0BMVR9i9bYR_MneVPWnrOw@mail.gmail.com>
Message-ID: <1dbeda36e0cf9c600508bc6d27973964.NginxMailingListRussian@forum.nginx.org>

Уже пробовал SSL Labs. Результат 1 ошибка для IE 8 / XP   No FS 1   No SNI
2	Server sent fatal alert: handshake_failure, остальные все тесты проходят.


Тот же яндекс без проблем открывается на этой старой ОС. Неужели дело в
бесплатном сертификате? Нашел пару сайтов с этим же сертификатом - тоже не
открываются. Хотя на сайте Let’s Encrypt написано, что все должно работать:

Known Compatible
Internet Explorer on Windows XP SP3 and higher

Не могу понять причину. Подскажите, как хоть вычислить кто виноват?

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


From chipitsine на gmail.com  Fri Jul 10 10:35:11 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 10 Jul 2020 15:35:11 +0500
Subject: =?UTF-8?B?UmU6IFNTTCDQtNC70Y8gSUUgOA==?=
In-Reply-To: <1dbeda36e0cf9c600508bc6d27973964.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQG8nzwyFE7te0mQe4TdZvPd0BMVR9i9bYR_MneVPWnrOw@mail.gmail.com>
 <1dbeda36e0cf9c600508bc6d27973964.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQFoYV_2u+w6WpVwbyqq8ZT3ig8n5wC+GaFQtO_+rjwakQ@mail.gmail.com>

вы сайт уже в интернет выставили ? дайте адрес ?


пт, 10 июл. 2020 г. в 14:23, grey <nginx-forum на forum.nginx.org>:

> Уже пробовал SSL Labs. Результат 1 ошибка для IE 8 / XP   No FS 1   No SNI
> 2       Server sent fatal alert: handshake_failure, остальные все тесты
> проходят.
>
>
> Тот же яндекс без проблем открывается на этой старой ОС. Неужели дело в
> бесплатном сертификате? Нашел пару сайтов с этим же сертификатом - тоже не
> открываются. Хотя на сайте Let’s Encrypt написано, что все должно работать:
>
> Known Compatible
> Internet Explorer on Windows XP SP3 and higher
>
> Не могу понять причину. Подскажите, как хоть вычислить кто виноват?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288640,288654#msg-288654
>
> _______________________________________________
> 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/20200710/a9c40a1d/attachment.htm>

From nginx-forum на forum.nginx.org  Fri Jul 10 11:59:41 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Fri, 10 Jul 2020 07:59:41 -0400
Subject: =?UTF-8?B?UmU6IFNTTCDQtNC70Y8gSUUgOA==?=
In-Reply-To: <CAFHpkQFoYV_2u+w6WpVwbyqq8ZT3ig8n5wC+GaFQtO_+rjwakQ@mail.gmail.com>
References: <CAFHpkQFoYV_2u+w6WpVwbyqq8ZT3ig8n5wC+GaFQtO_+rjwakQ@mail.gmail.com>
Message-ID: <af512fb167d953d4e28e5fcaad2dad5e.NginxMailingListRussian@forum.nginx.org>

Нет, сайт в интернете не доступен еще. Но например, вот аналогичный сайт с
такой же проблемой https://helloworld.letsencrypt.org/ от самого издателя
сертификата.

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


From chipitsine на gmail.com  Fri Jul 10 12:47:28 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 10 Jul 2020 17:47:28 +0500
Subject: =?UTF-8?B?UmU6IFNTTCDQtNC70Y8gSUUgOA==?=
In-Reply-To: <af512fb167d953d4e28e5fcaad2dad5e.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQFoYV_2u+w6WpVwbyqq8ZT3ig8n5wC+GaFQtO_+rjwakQ@mail.gmail.com>
 <af512fb167d953d4e28e5fcaad2dad5e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQH7MG1w4zNPDTBh18Viq1JfqSbxnDDVNKPdxj349dFOrA@mail.gmail.com>

у приведенного примера не включен шифр DES-CBC3-SHA
у вас он включен ? попробуйте его добавить

пт, 10 июл. 2020 г. в 16:59, grey <nginx-forum на forum.nginx.org>:

> Нет, сайт в интернете не доступен еще. Но например, вот аналогичный сайт с
> такой же проблемой https://helloworld.letsencrypt.org/ от самого издателя
> сертификата.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288640,288656#msg-288656
>
> _______________________________________________
> 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/20200710/b24f87df/attachment.htm>

From chipitsine на gmail.com  Fri Jul 10 12:49:52 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 10 Jul 2020 17:49:52 +0500
Subject: =?UTF-8?B?UmU6IFNTTCDQtNC70Y8gSUUgOA==?=
In-Reply-To: <af512fb167d953d4e28e5fcaad2dad5e.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQFoYV_2u+w6WpVwbyqq8ZT3ig8n5wC+GaFQtO_+rjwakQ@mail.gmail.com>
 <af512fb167d953d4e28e5fcaad2dad5e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQFVhTMnMWXw8pCUXpup29OycNDstw1oiT=QqikVBB4qjA@mail.gmail.com>

"не доступен еще", но скоро планируется? дадите адрес, когда будет доступен
?

пт, 10 июл. 2020 г. в 16:59, grey <nginx-forum на forum.nginx.org>:

> Нет, сайт в интернете не доступен еще. Но например, вот аналогичный сайт с
> такой же проблемой https://helloworld.letsencrypt.org/ от самого издателя
> сертификата.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288640,288656#msg-288656
>
> _______________________________________________
> 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/20200710/36cfbbde/attachment.htm>

From nginx-forum на forum.nginx.org  Wed Jul 15 07:40:46 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Wed, 15 Jul 2020 03:40:46 -0400
Subject: =?UTF-8?B?0KDQtdC00LjRgNC10LrRgiDRgSBodHRwINC90LAgaHR0cHMg0L3QsCDQvtC00L0=?=
 =?UTF-8?B?0L7QvCDQuCDRgtC+0Lwg0LbQtSDRgdC10YDQstC10YDQtQ==?=
Message-ID: <aae0b22b8ef1489e8418ba7b23627b10.NginxMailingListRussian@forum.nginx.org>

Приветствую всех!
Нужна помощь...

Раньше был сайт http://site1.com на одном хостинге (apache). Теперь
перенесли его на другой хостинг с сертификатом https://site1.com (nginx).
Теперь мне нужно чтобы новый сайт грамотно редиректил http на https,
то-есть:
http://site1.com/page1 -> https://site1.com/art/page1
http://site1.com/page2 -> https://site1.com/blog/page11
...

Сейчас в nginx на https://site1.com у меня такие блоки:

server {
  listen 80;
  server_name www.site1.com site1.com;
  
  rewrite http://site1.com/page1 https://site1.com/page1 permanent;

  if ($request_uri = /index.html) {
    return 301 https://site1.com;
  }
  return 301 https://site1.com$request_uri;
}

server {
  listen 443 default ssl;
  server_name site1.com;
  rewrite ^/(.*)/$ /$1 permanent;

  root /.../public;

  ssl_certificate /...;
  ssl_certificate_key /...;
  ssl_session_timeout 5m;
}

но rewrite http://site1.com/page1 https://site1.com/page1 permanent; не
срабатывает.
что не так делаю?

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


From root на dl.sm.ua  Wed Jul 15 08:13:42 2020
From: root на dl.sm.ua (Dmytro Lavryk)
Date: Wed, 15 Jul 2020 11:13:42 +0300
Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0YEgaHR0cCDQvdCwIGh0dHBzINC90LAg0L4=?=
 =?UTF-8?B?0LTQvdC+0Lwg0Lgg0YLQvtC8INC20LUg0YHQtdGA0LLQtdGA0LU=?=
In-Reply-To: <aae0b22b8ef1489e8418ba7b23627b10.NginxMailingListRussian@forum.nginx.org>
References: <aae0b22b8ef1489e8418ba7b23627b10.NginxMailingListRussian@forum.nginx.org>
Message-ID: <17351895913.cb0d4ed3126465.3625356165179490214@dl.sm.ua>

   if ($ssl_protocol = "") {

        rewrite ^   https://sorp.ae$request_uri permanent;

    }


___________

С уважением, Дмитрий Лаврик



WWW: https://dl.sm.ua

E-mail: mailto:me на dl.sm.ua

Telegram: dlsumy

Тел. (viber): +380506037953

Skype: dmytro.lavryk

Facebook: https://www.facebook.com/dmytro.lavryk





---- Увімкнуто ср, 15 лип. 2020 10:40:46 +0300 akoval <nginx-forum на forum.nginx.org> написав ----


Приветствую всех!
Нужна помощь...

Раньше был сайт http://site1.com на одном хостинге (apache). Теперь
перенесли его на другой хостинг с сертификатом https://site1.com (nginx).
Теперь мне нужно чтобы новый сайт грамотно редиректил http на https,
то-есть:
http://site1.com/page1 -> https://site1.com/art/page1
http://site1.com/page2 -> https://site1.com/blog/page11
...

Сейчас в nginx на https://site1.com у меня такие блоки:

server {
 listen 80;
 server_name www.site1.com site1.com;
 
 rewrite http://site1.com/page1 https://site1.com/page1 permanent;

 if ($request_uri = /index.html) {
 return 301 https://site1.com;
 }
 return 301 https://site1.com$request_uri;
}

server {
 listen 443 default ssl;
 server_name site1.com;
 rewrite ^/(.*)/$ /$1 permanent;

 root /.../public;

 ssl_certificate /...;
 ssl_certificate_key /...;
 ssl_session_timeout 5m;
}

но rewrite http://site1.com/page1 https://site1.com/page1 permanent; не
срабатывает.
что не так делаю?

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

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

From chipitsine на gmail.com  Wed Jul 15 08:26:34 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 15 Jul 2020 13:26:34 +0500
Subject: =?UTF-8?B?0YPRj9C30LLQuNC80L7RgdGC0Ywg0LIg0YDQtdCy0LXRgNGBLdC/0YDQvtC60YE=?=
 =?UTF-8?B?0LjRgNC+0LLQsNC90LjQuA==?=
Message-ID: <CAFHpkQHWcwrmsgm__G0vFrcuUQFCXM3UfgN=SArcFNGzTTnMXA@mail.gmail.com>

привет!

конкретики, к сожалению, почти нет
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV200008

если у кого-то есть конкретика, поделитесь, плиз ?

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

From kulmaks на gmail.com  Wed Jul 15 08:52:55 2020
From: kulmaks на gmail.com (Maksim Kulik)
Date: Wed, 15 Jul 2020 11:52:55 +0300
Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0YEgaHR0cCDQvdCwIGh0dHBzINC90LAg0L4=?=
 =?UTF-8?B?0LTQvdC+0Lwg0Lgg0YLQvtC8INC20LUg0YHQtdGA0LLQtdGA0LU=?=
In-Reply-To: <17351895913.cb0d4ed3126465.3625356165179490214@dl.sm.ua>
References: <aae0b22b8ef1489e8418ba7b23627b10.NginxMailingListRussian@forum.nginx.org>
 <17351895913.cb0d4ed3126465.3625356165179490214@dl.sm.ua>
Message-ID: <CA+zavHkjGa2yQ5LpFCZEVgmX9Do_HfQ79iEq_8b0ZyC3MyRsWA@mail.gmail.com>

Можно еще короче. В блоке сервера для 80 порта указать:

return 301 https://$host$request_uri;



ср, 15 июл. 2020 г. в 11:14, Dmytro Lavryk <root на dl.sm.ua>:

>    if ($ssl_protocol = "") {
>         rewrite ^   https://$host$request_uri
> <https://sorp.ae$request_uri> permanent;
>     }
>
>
> ---- Увімкнуто ср, 15 лип. 2020 10:40:46 +0300 *akoval
> <nginx-forum на forum.nginx.org <nginx-forum на forum.nginx.org>>* написав ----
>
> Приветствую всех!
> Нужна помощь...
>
> Раньше был сайт http://site1.com на одном хостинге (apache). Теперь
> перенесли его на другой хостинг с сертификатом https://site1.com (nginx).
> Теперь мне нужно чтобы новый сайт грамотно редиректил http на https,
> то-есть:
> http://site1.com/page1 -> https://site1.com/art/page1
> http://site1.com/page2 -> https://site1.com/blog/page11
> ...
>
> Сейчас в nginx на https://site1.com у меня такие блоки:
>
> server {
> listen 80;
> server_name www.site1.com site1.com;
>
> rewrite http://site1.com/page1 https://site1.com/page1 permanent;
>
> if ($request_uri = /index.html) {
> return 301 https://site1.com;
> }
> return 301 https://site1.com$request_uri;
> }
>
> server {
> listen 443 default ssl;
> server_name site1.com;
> rewrite ^/(.*)/$ /$1 permanent;
>
> root /.../public;
>
> ssl_certificate /...;
> ssl_certificate_key /...;
> ssl_session_timeout 5m;
> }
>
> но rewrite http://site1.com/page1 https://site1.com/page1 permanent; не
> срабатывает.
> что не так делаю?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288702,288702#msg-288702
>
> _______________________________________________
> 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/20200715/a51dad42/attachment-0001.htm>

From nginx-forum на forum.nginx.org  Wed Jul 15 10:18:58 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Wed, 15 Jul 2020 06:18:58 -0400
Subject: =?UTF-8?B?0J/Rg9GC0LDQvdC40YbQsCDQsiDQv9C+0YHQu9C10LTQvtCy0LDRgtC10LvRjNC9?=
 =?UTF-8?B?0L7RgdGC0Ywg0LfQsNC/0LjRgdC10Lkg0LIg0LvQvtCz0LDRhQ==?=
Message-ID: <4e0d027b3f823fb8c94473cb32feece4.NginxMailingListRussian@forum.nginx.org>

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


Заметил тут одну вещь: в файле access.log время запросов идет не по порядку,
например:

127.0.0.1 - - [12/Jul/2020:23:30:00 +0300] "GET /nginx-status HTTP/1.0" 200
117 "-" "-"
127.0.0.1 - - [13/Jul/2020:00:15:00 +0300] "GET /nginx-status HTTP/1.0" 200
117 "-" "-"
127.0.0.1 - - [13/Jul/2020:00:45:00 +0300] "GET /nginx-status HTTP/1.0" 200
117 "-" "-"
127.0.0.1 - - [12/Jul/2020:03:00:00 +0300] "GET /nginx-status HTTP/1.0" 200
117 "-" "-"

или вот

127.0.0.1 - - [12/Jul/2020:02:20:00 +0300] "GET /nginx-status HTTP/1.0" 200
117 "-" "-"
45.157.*.* - - [12/Jul/2020:02:23:53 +0300] "GET / HTTP/1.1" 403 548 "-"
"Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/52.0.2743.116 Safari/537.36"
127.0.0.1 - - [12/Jul/2020:02:30:00 +0300] "GET /nginx-status HTTP/1.0" 200
117 "-" "-"
127.0.0.1 - - [11/Jul/2020:02:40:00 +0300] "GET /nginx-status HTTP/1.0" 200
117 "-" "-"

Начал разбираться. Вот что выяснил - существует две конфигурации для двух
разных адресов:
1. server
{
	listen 127.0.0.1:80;
	server_name 127.0.0.1;

	location /nginx-status 	{ 		stub_status;	}
}

2. server {
	listen       80;
	server_name  11.22.33.44;

	access_log  logs/access.log  combined buffer=64k;
...
}

Я так понимаю дело в буферизации. Но почему конфигурация 2 с включенной
буферизацией влияет на конфигурацию 1 на запись логов без буфера? По идее
логи о состоянии сервера при обращении с локального адреса 127.0.0.1 должны
писаться сразу в файл, а с внешнего адреса - блоками по 64Кб.

В принципе, меня устроит однословный ответ разработчиков что все ок и так и
задумано или это баг :)

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


From kulmaks на gmail.com  Wed Jul 15 10:32:53 2020
From: kulmaks на gmail.com (Maksim Kulik)
Date: Wed, 15 Jul 2020 13:32:53 +0300
Subject: =?UTF-8?B?UmU6INCf0YPRgtCw0L3QuNGG0LAg0LIg0L/QvtGB0LvQtdC00L7QstCw0YLQtdC7?=
 =?UTF-8?B?0YzQvdC+0YHRgtGMINC30LDQv9C40YHQtdC5INCyINC70L7Qs9Cw0YU=?=
In-Reply-To: <4e0d027b3f823fb8c94473cb32feece4.NginxMailingListRussian@forum.nginx.org>
References: <4e0d027b3f823fb8c94473cb32feece4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CA+zavHnXPweQ8fCZwhntU983RZxWpKyBgkkjZsQch4ThfH4B-w@mail.gmail.com>

Добрый день.
А где конфигурация access_log для локалхоста? Думаю следует явно указать
его в этом блоке server и проблема пропадет.

ср, 15 июл. 2020 г. в 13:19, grey <nginx-forum на forum.nginx.org>:

> Приветствую всех!
>
>
> Заметил тут одну вещь: в файле access.log время запросов идет не по
> порядку,
> например:
>
> 1. server
> {
>         listen 127.0.0.1:80;
>         server_name 127.0.0.1;
>
>         location /nginx-status  {               stub_status;    }
> }
>
> 2. server {
>         listen       80;
>         server_name  11.22.33.44;
>
>         access_log  logs/access.log  combined buffer=64k;
> ...
> }
>
>
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288706,288706#msg-288706
>
> _______________________________________________
> 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/20200715/22fd6881/attachment.htm>

From nginx-forum на forum.nginx.org  Wed Jul 15 10:40:21 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Wed, 15 Jul 2020 06:40:21 -0400
Subject: =?UTF-8?B?UmU6INCf0YPRgtCw0L3QuNGG0LAg0LIg0L/QvtGB0LvQtdC00L7QstCw0YLQtdC7?=
 =?UTF-8?B?0YzQvdC+0YHRgtGMINC30LDQv9C40YHQtdC5INCyINC70L7Qs9Cw0YU=?=
In-Reply-To: <CA+zavHnXPweQ8fCZwhntU983RZxWpKyBgkkjZsQch4ThfH4B-w@mail.gmail.com>
References: <CA+zavHnXPweQ8fCZwhntU983RZxWpKyBgkkjZsQch4ThfH4B-w@mail.gmail.com>
Message-ID: <45c9616edcc7932dd8fde50ba1a8be16.NginxMailingListRussian@forum.nginx.org>

Конфигурация логов для локалхоста не указана, т.к. в доках написано:
===
Умолчание: 	

access_log logs/access.log combined;
===

Что в принципе так и есть.

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


From pluknet на nginx.com  Wed Jul 15 11:29:55 2020
From: pluknet на nginx.com (Sergey Kandaurov)
Date: Wed, 15 Jul 2020 14:29:55 +0300
Subject: =?UTF-8?B?UmU6INCf0YPRgtCw0L3QuNGG0LAg0LIg0L/QvtGB0LvQtdC00L7QstCw0YLQtdC7?=
 =?UTF-8?B?0YzQvdC+0YHRgtGMINC30LDQv9C40YHQtdC5INCyINC70L7Qs9Cw0YU=?=
In-Reply-To: <4e0d027b3f823fb8c94473cb32feece4.NginxMailingListRussian@forum.nginx.org>
References: <4e0d027b3f823fb8c94473cb32feece4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <01965A3B-4499-4AEA-8005-CD1792417598@nginx.com>


> On 15 Jul 2020, at 13:18, grey <nginx-forum на forum.nginx.org> wrote:
> 
> Приветствую всех!
> 
> 
> Заметил тут одну вещь: в файле access.log время запросов идет не по порядку,
> например:
> 
> 127.0.0.1 - - [12/Jul/2020:23:30:00 +0300] "GET /nginx-status HTTP/1.0" 200
> 117 "-" "-"
> 127.0.0.1 - - [13/Jul/2020:00:15:00 +0300] "GET /nginx-status HTTP/1.0" 200
> 117 "-" "-"
> 127.0.0.1 - - [13/Jul/2020:00:45:00 +0300] "GET /nginx-status HTTP/1.0" 200
> 117 "-" "-"
> 127.0.0.1 - - [12/Jul/2020:03:00:00 +0300] "GET /nginx-status HTTP/1.0" 200
> 117 "-" "-"
> 
> или вот
> 
> 127.0.0.1 - - [12/Jul/2020:02:20:00 +0300] "GET /nginx-status HTTP/1.0" 200
> 117 "-" "-"
> 45.157.*.* - - [12/Jul/2020:02:23:53 +0300] "GET / HTTP/1.1" 403 548 "-"
> "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
> Chrome/52.0.2743.116 Safari/537.36"
> 127.0.0.1 - - [12/Jul/2020:02:30:00 +0300] "GET /nginx-status HTTP/1.0" 200
> 117 "-" "-"
> 127.0.0.1 - - [11/Jul/2020:02:40:00 +0300] "GET /nginx-status HTTP/1.0" 200
> 117 "-" "-"
> 
> Начал разбираться. Вот что выяснил - существует две конфигурации для двух
> разных адресов:
> 1. server
> {
> 	listen 127.0.0.1:80;
> 	server_name 127.0.0.1;
> 
> 	location /nginx-status 	{ 		stub_status;	}
> }
> 
> 2. server {
> 	listen       80;
> 	server_name  11.22.33.44;
> 
> 	access_log  logs/access.log  combined buffer=64k;
> ...
> }
> 
> Я так понимаю дело в буферизации. Но почему конфигурация 2 с включенной
> буферизацией влияет на конфигурацию 1 на запись логов без буфера? По идее
> логи о состоянии сервера при обращении с локального адреса 127.0.0.1 должны
> писаться сразу в файл, а с внешнего адреса - блоками по 64Кб.
> 
> В принципе, меня устроит однословный ответ разработчиков что все ок и так и
> задумано или это баг :)

В данном случае это один и тот же файл logs/access.log,
а значит и параметры буферизации в разных блоках server общие.
Здесь во 2-м блоке server параметр buffer=64k проапдейтил
существующую конфигурацию, что примерно соответствует:

server {
	listen 127.0.0.1:80;
	server_name 127.0.0.1;

	access_log  logs/access.log  combined buffer=64k;
	location /nginx-status 	{ 		stub_status;	}
}

server {
	listen       80;
	server_name  11.22.33.44;

	access_log  logs/access.log  combined buffer=64k;
}

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

-- 
Sergey Kandaurov


From nginx-forum на forum.nginx.org  Wed Jul 15 11:34:50 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Wed, 15 Jul 2020 07:34:50 -0400
Subject: =?UTF-8?B?UmU6INCg0LXQtNC40YDQtdC60YIg0YEgaHR0cCDQvdCwIGh0dHBzINC90LAg0L4=?=
 =?UTF-8?B?0LTQvdC+0Lwg0Lgg0YLQvtC8INC20LUg0YHQtdGA0LLQtdGA0LU=?=
In-Reply-To: <CA+zavHkjGa2yQ5LpFCZEVgmX9Do_HfQ79iEq_8b0ZyC3MyRsWA@mail.gmail.com>
References: <CA+zavHkjGa2yQ5LpFCZEVgmX9Do_HfQ79iEq_8b0ZyC3MyRsWA@mail.gmail.com>
Message-ID: <26db547559de95a6c66e0f87a1c369ce.NginxMailingListRussian@forum.nginx.org>

спасибо, заработало.
а как сделать редирект без слеша в конце?

напр
rewrite http://site1.com/aaa/ https://site1.com/bbb permanent; - работает 
rewrite http://site1.com/aaa https://site1.com/bbb permanent; - а так уже не
хочет

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


From nginx-forum на forum.nginx.org  Wed Jul 15 11:36:10 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Wed, 15 Jul 2020 07:36:10 -0400
Subject: =?UTF-8?B?UmU6INCf0YPRgtCw0L3QuNGG0LAg0LIg0L/QvtGB0LvQtdC00L7QstCw0YLQtdC7?=
 =?UTF-8?B?0YzQvdC+0YHRgtGMINC30LDQv9C40YHQtdC5INCyINC70L7Qs9Cw0YU=?=
In-Reply-To: <01965A3B-4499-4AEA-8005-CD1792417598@nginx.com>
References: <01965A3B-4499-4AEA-8005-CD1792417598@nginx.com>
Message-ID: <387477760051855ad85648eacf8cffc6.NginxMailingListRussian@forum.nginx.org>

Понятно, я в принципе так и думал, но на всякий случай уточнил :)

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


From nginx-forum на forum.nginx.org  Wed Jul 15 12:13:47 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Wed, 15 Jul 2020 08:13:47 -0400
Subject: =?UTF-8?B?bmdpbnguINGA0LXQtNC40YDQtdC60YIg0YPRgNC70LAg0LHQtdC3INGB0LvQtdGI?=
 =?UTF-8?B?0LAg0LIg0LrQvtC90YbQtT8=?=
Message-ID: <7e49d6110088a0f6ecbfb49423d3aa7d.NginxMailingListRussian@forum.nginx.org>

Напр:
rewrite http://site1.com/aaa/ https://site1.com/bbb permanent; - работает
rewrite http://site1.com/aaa https://site1.com/bbb permanent; - а так уже не
хочет

Пробую разные регулярки, но пока не работает:
rewrite ^/ua/about/loyalty-program/?$ https://apteka-ds.com.ua/discount
permanent;

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


From igor на sysoev.ru  Wed Jul 15 12:17:22 2020
From: igor на sysoev.ru (Igor Sysoev)
Date: Wed, 15 Jul 2020 15:17:22 +0300
Subject: =?UTF-8?B?UmU6IG5naW54LiDRgNC10LTQuNGA0LXQutGCINGD0YDQu9CwINCx0LXQtyDRgdC7?=
 =?UTF-8?B?0LXRiNCwINCyINC60L7QvdGG0LU/?=
In-Reply-To: <7e49d6110088a0f6ecbfb49423d3aa7d.NginxMailingListRussian@forum.nginx.org>
References: <7e49d6110088a0f6ecbfb49423d3aa7d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <E1F70CFB-FDBE-4DEE-9639-F6B03B03B2C0@sysoev.ru>

> On 15 Jul 2020, at 15:13, akoval <nginx-forum на forum.nginx.org> wrote:
> 
> Напр:
> rewrite http://site1.com/aaa/ https://site1.com/bbb permanent; - работает
> rewrite http://site1.com/aaa https://site1.com/bbb permanent; - а так уже не
> хочет
> 
> Пробую разные регулярки, но пока не работает:
> rewrite ^/ua/about/loyalty-program/?$ https://apteka-ds.com.ua/discount
> permanent;

location /ua/about/loyalty-program {
    return 301 https://apteka-ds.com.ua/discount;
}


-- 
Igor Sysoev

From nginx-forum на forum.nginx.org  Wed Jul 15 13:31:39 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Wed, 15 Jul 2020 09:31:39 -0400
Subject: =?UTF-8?B?UmU6IG5naW54LiDRgNC10LTQuNGA0LXQutGCINGD0YDQu9CwINCx0LXQtyDRgdC7?=
 =?UTF-8?B?0LXRiNCwINCyINC60L7QvdGG0LU/?=
In-Reply-To: <E1F70CFB-FDBE-4DEE-9639-F6B03B03B2C0@sysoev.ru>
References: <E1F70CFB-FDBE-4DEE-9639-F6B03B03B2C0@sysoev.ru>
Message-ID: <076c8c98b72fa9cda3703e956222243e.NginxMailingListRussian@forum.nginx.org>

location /ua/about/loyalty-program { return 301
https://apteka-ds.com.ua/discount; }
location /ua/about { return 301 https://apteka-ds.com.ua/about-us permanent;
}
location /ua/about/contacts { return 301 https://apteka-ds.com.ua/contacts
permanent; }
location /ua/files/docs/loyalty/Договір_Клієнта.pdf { return 301
https://apteka-ds.com.ua/loyalty/Договір_Клієнта.pdf permanent; }
  
  # articles
  rewrite /ua/articles/koronavirus-vse-shcho-potribno-znaty-pro-nogo/
https://apteka-ds.com.ua/blog-item/koronavirus-vse-shcho-potribno-znaty-pro-noho/
permanent;


в данном контексте при заходе на
http://apteka-ds.com.ua/ua/about/loyalty-program
перекидає на https://apteka-ds.com.ua/about-us
?

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


From igor на sysoev.ru  Wed Jul 15 13:41:02 2020
From: igor на sysoev.ru (Igor Sysoev)
Date: Wed, 15 Jul 2020 16:41:02 +0300
Subject: =?UTF-8?B?UmU6IG5naW54LiDRgNC10LTQuNGA0LXQutGCINGD0YDQu9CwINCx0LXQtyDRgdC7?=
 =?UTF-8?B?0LXRiNCwINCyINC60L7QvdGG0LU/?=
In-Reply-To: <076c8c98b72fa9cda3703e956222243e.NginxMailingListRussian@forum.nginx.org>
References: <E1F70CFB-FDBE-4DEE-9639-F6B03B03B2C0@sysoev.ru>
 <076c8c98b72fa9cda3703e956222243e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5FF2827C-5827-4E5F-835B-FC19AEC10F6E@sysoev.ru>

Уберите реврайты из конфига, возможно срабатывает какой-то реврайт.

location /ua/articles/koronavirus-vse-shcho-potribno-znaty-pro-nogo/
    return 301 https://apteka-ds.com.ua/blog-item/koronavirus-vse-shcho-potribno-znaty-pro-noho/;
}

-- 
Igor Sysoev

> On 15 Jul 2020, at 16:31, akoval <nginx-forum на forum.nginx.org> wrote:
> 
> location /ua/about/loyalty-program { return 301
> https://apteka-ds.com.ua/discount; }
> location /ua/about { return 301 https://apteka-ds.com.ua/about-us permanent;
> }
> location /ua/about/contacts { return 301 https://apteka-ds.com.ua/contacts
> permanent; }
> location /ua/files/docs/loyalty/Договір_Клієнта.pdf { return 301
> https://apteka-ds.com.ua/loyalty/Договір_Клієнта.pdf permanent; }
> 
>  # articles
>  rewrite /ua/articles/koronavirus-vse-shcho-potribno-znaty-pro-nogo/
> https://apteka-ds.com.ua/blog-item/koronavirus-vse-shcho-potribno-znaty-pro-noho/
> permanent;
> 
> 
> в данном контексте при заходе на
> http://apteka-ds.com.ua/ua/about/loyalty-program
> перекидає на https://apteka-ds.com.ua/about-us
> ?


From nginx-forum на forum.nginx.org  Wed Jul 15 14:19:28 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Wed, 15 Jul 2020 10:19:28 -0400
Subject: =?UTF-8?B?UmU6IG5naW54LiDRgNC10LTQuNGA0LXQutGCINGD0YDQu9CwINCx0LXQtyDRgdC7?=
 =?UTF-8?B?0LXRiNCwINCyINC60L7QvdGG0LU/?=
In-Reply-To: <5FF2827C-5827-4E5F-835B-FC19AEC10F6E@sysoev.ru>
References: <5FF2827C-5827-4E5F-835B-FC19AEC10F6E@sysoev.ru>
Message-ID: <19a575238fb4786edbb5907dea48598c.NginxMailingListRussian@forum.nginx.org>

location /ua/about/loyalty-program { return 301
https://apteka-ds.com.ua/discount; }
  location /ua/about { return 301 https://apteka-ds.com.ua/about-us; }
  location /ua/about/contacts { return 301
https://apteka-ds.com.ua/contacts; }
  location /ua/files/docs/loyalty/Договір_Клієнта.pdf { return 301
https://apteka-ds.com.ua/loyalty/Договір_Клієнта.pdf; }
  
  # articles
  location /ua/articles/koronavirus-vse-shcho-potribno-znaty-pro-nogo/ {
return 301
https://apteka-ds.com.ua/blog-item/koronavirus-vse-shcho-potribno-znaty-pro-noho/;
}
...

return 301 https://$host$request_uri;

с location вообще все перестало работать (

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


From nginx-forum на forum.nginx.org  Wed Jul 15 14:23:40 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Wed, 15 Jul 2020 10:23:40 -0400
Subject: =?UTF-8?B?UmU6IG5naW54LiDRgNC10LTQuNGA0LXQutGCINGD0YDQu9CwINCx0LXQtyDRgdC7?=
 =?UTF-8?B?0LXRiNCwINCyINC60L7QvdGG0LU/?=
In-Reply-To: <19a575238fb4786edbb5907dea48598c.NginxMailingListRussian@forum.nginx.org>
References: <5FF2827C-5827-4E5F-835B-FC19AEC10F6E@sysoev.ru>
 <19a575238fb4786edbb5907dea48598c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <e8cc2a3deb4848c3acb0f61dc46df2da.NginxMailingListRussian@forum.nginx.org>

видимо эта строка return 301 https://$host$request_uri; все портит.
как тогда правильно ее в конце прописать? если не зашло ни на один location,
тогда идем на https?

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


From pluknet на nginx.com  Wed Jul 15 14:39:28 2020
From: pluknet на nginx.com (Sergey Kandaurov)
Date: Wed, 15 Jul 2020 17:39:28 +0300
Subject: =?UTF-8?B?UmU6IG5naW54LiDRgNC10LTQuNGA0LXQutGCINGD0YDQu9CwINCx0LXQtyDRgdC7?=
 =?UTF-8?B?0LXRiNCwINCyINC60L7QvdGG0LU/?=
In-Reply-To: <e8cc2a3deb4848c3acb0f61dc46df2da.NginxMailingListRussian@forum.nginx.org>
References: <5FF2827C-5827-4E5F-835B-FC19AEC10F6E@sysoev.ru>
 <19a575238fb4786edbb5907dea48598c.NginxMailingListRussian@forum.nginx.org>
 <e8cc2a3deb4848c3acb0f61dc46df2da.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5875FB2C-48A6-4F1F-9834-5AB8A74EC38D@nginx.com>


> On 15 Jul 2020, at 17:23, akoval <nginx-forum на forum.nginx.org> wrote:
> 
> видимо эта строка return 301 https://$host$request_uri; все портит.

rewrite на уровне сервера срабатывает до сопоставления uri / location.

> как тогда правильно ее в конце прописать? если не зашло ни на один location,
> тогда идем на https?

Например, положить в наименее специфичный location:

location / {
    return 301 https://$host$request_uri;
}

-- 
Sergey Kandaurov


From gmm на csdoc.com  Wed Jul 15 14:39:44 2020
From: gmm на csdoc.com (Gena Makhomed)
Date: Wed, 15 Jul 2020 17:39:44 +0300
Subject: =?UTF-8?B?UmU6IG5naW54LiDRgNC10LTQuNGA0LXQutGCINGD0YDQu9CwINCx0LXQtyDRgdC7?=
 =?UTF-8?B?0LXRiNCwINCyINC60L7QvdGG0LU/?=
In-Reply-To: <e8cc2a3deb4848c3acb0f61dc46df2da.NginxMailingListRussian@forum.nginx.org>
References: <5FF2827C-5827-4E5F-835B-FC19AEC10F6E@sysoev.ru>
 <19a575238fb4786edbb5907dea48598c.NginxMailingListRussian@forum.nginx.org>
 <e8cc2a3deb4848c3acb0f61dc46df2da.NginxMailingListRussian@forum.nginx.org>
Message-ID: <66e0685e-78ee-a68c-f3a5-2906018f88d4@csdoc.com>

On 15.07.2020 17:23, akoval wrote:

> видимо эта строка return 301 https://$host$request_uri; все портит.
> как тогда правильно ее в конце прописать? если не зашло ни на один location,
> тогда идем на https?

вот эту строку:

return 301 https://$host$request_uri;

надо писать не в контексте server, а в контексте location /, тогда все 
будет работать:

location / {
     return 301 https://$host$request_uri;
}

все остальные 301 редиректы - в своих собственных location`ах.

полезная статья:

http://nginx.org/ru/docs/http/request_processing.html
Как nginx обрабатывает запросы

полезная документация:

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

-- 
Best regards,
  Gena


From red-fox0 на ya.ru  Wed Jul 15 14:42:15 2020
From: red-fox0 на ya.ru (fox)
Date: Wed, 15 Jul 2020 21:42:15 +0700
Subject: =?UTF-8?B?UmU6IG5naW54LiDRgNC10LTQuNGA0LXQutGCINGD0YDQu9CwINCx0LXQtyDRgdC7?=
 =?UTF-8?B?0LXRiNCwINCyINC60L7QvdGG0LU/?=
In-Reply-To: <e8cc2a3deb4848c3acb0f61dc46df2da.NginxMailingListRussian@forum.nginx.org>
References: <5FF2827C-5827-4E5F-835B-FC19AEC10F6E@sysoev.ru>
 <19a575238fb4786edbb5907dea48598c.NginxMailingListRussian@forum.nginx.org>
 <e8cc2a3deb4848c3acb0f61dc46df2da.NginxMailingListRussian@forum.nginx.org>
Message-ID: <7ef18148-193d-1066-e9f9-e529c447ee7c@ya.ru>

location / {
  return 301 https://$host$request_uri;
}

location /ua/about/loyalty-program {
  return 301 https://apteka-ds.com.ua/discount;
}

# ...


15.07.2020 21:23, akoval пишет:
> видимо эта строка return 301 https://$host$request_uri; все портит.
> как тогда правильно ее в конце прописать? если не зашло ни на один location,
> тогда идем на https?
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288714,288721#msg-288721
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 


From nginx-forum на forum.nginx.org  Wed Jul 15 14:50:45 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Wed, 15 Jul 2020 10:50:45 -0400
Subject: =?UTF-8?B?UmU6IG5naW54LiDRgNC10LTQuNGA0LXQutGCINGD0YDQu9CwINCx0LXQtyDRgdC7?=
 =?UTF-8?B?0LXRiNCwINCyINC60L7QvdGG0LU/?=
In-Reply-To: <7ef18148-193d-1066-e9f9-e529c447ee7c@ya.ru>
References: <7ef18148-193d-1066-e9f9-e529c447ee7c@ya.ru>
Message-ID: <589db483bcce568cb9676122cdfd32b7.NginxMailingListRussian@forum.nginx.org>

всем спасибо!

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


From nginx на mva.name  Thu Jul 16 10:13:22 2020
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 16 Jul 2020 17:13:22 +0700
Subject: [Unit] [error] 28#39 *18 mkstemp() failed (2: No such file or
 directory)
Message-ID: <1612848.uBFMFrglHY@note>

Здравствуйте, сообщество и уважаемые разработчики!
На одном из проектов мы используем Docker-контейнеры с alpine linux, в которых 
стоит Unit с питоно-модулем, а так же задеплоенное Django-приложение.

И вот уже на втором проекте мы сталкиваемся с ошибкой, процитированной в 
заголовке при сохранении данных из админки джанго. Что интересно, данные 
сохраняются в базу, и там вообще копеечный объём.

Если честно, я не очень понимаю что именно происходит в блоке if (что именно 
за функция nxt_slow_path и что она делает. Так и не удалось найти её 
определение): https://github.com/nginx/unit/blob/
65799c7252e56d287d967bf3f036a10d5764f82c/src/nxt_h1proto.c#L907-L913

поэтому и не имею понятия как бы можно было эту проблему обойти или починить.

К сожалению, в alpine нету debug-сборки юнита, а собирать самим - очень не 
хочется.

А если взять "официальный" докероимейдж юнита (на основе дебиана) - всё 
работает...

Но, всё же очень хотелось бы, чтобы alpine'овая сборка тоже работала...

Так что не могли бы вы помочь понять суть происходящего и подсказать как 
вылечить?


P.S. как я вижу выше по коду, более глобальной причиной является то, что   
(body_length > body_buffer_size).
Однако, я что-то нигде в документации юнита не могу найти крутилку максимально 
разрешённого body_buffer_size...

From eugen на grosbein.net  Thu Jul 16 10:33:36 2020
From: eugen на grosbein.net (Eugene Grosbein)
Date: Thu, 16 Jul 2020 17:33:36 +0700
Subject: [Unit] [error] 28#39 *18 mkstemp() failed (2: No such file or
 directory)
In-Reply-To: <1612848.uBFMFrglHY@note>
References: <1612848.uBFMFrglHY@note>
Message-ID: <9483f35f-5e18-4d28-84c7-ca2b9d346ada@grosbein.net>

16.07.2020 17:13, Vadim A. Misbakh-Soloviov пишет:
> Здравствуйте, сообщество и уважаемые разработчики!
> На одном из проектов мы используем Docker-контейнеры с alpine linux, в которых 
> стоит Unit с питоно-модулем, а так же задеплоенное Django-приложение.
> 
> И вот уже на втором проекте мы сталкиваемся с ошибкой, процитированной в 
> заголовке при сохранении данных из админки джанго. Что интересно, данные 
> сохраняются в базу, и там вообще копеечный объём.
> 
> Если честно, я не очень понимаю что именно происходит в блоке if (что именно 
> за функция nxt_slow_path и что она делает. Так и не удалось найти её 
> определение): https://github.com/nginx/unit/blob/
> 65799c7252e56d287d967bf3f036a10d5764f82c/src/nxt_h1proto.c#L907-L913

Похоже на некорректную настройку client_body_temp_path (несуществующий путь):
https://nginx.org/ru/docs/http/ngx_http_core_module.html#client_body_temp_path



From nginx на mva.name  Thu Jul 16 10:52:53 2020
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 16 Jul 2020 17:52:53 +0700
Subject: [Unit] [error] 28#39 *18 mkstemp() failed (2: No such file or
 directory)
In-Reply-To: <efc08902-af6b-8f59-e7f6-956e8935862e@grosbein.net>
References: <1612848.uBFMFrglHY@note>
 <9483f35f-5e18-4d28-84c7-ca2b9d346ada@grosbein.net>
 <efc08902-af6b-8f59-e7f6-956e8935862e@grosbein.net>
Message-ID: <4502606.cZfUaBzzB3@note>

> > Похоже на некорректную настройку client_body_temp_path (несуществующий
> > путь):
> > https://nginx.org/ru/docs/http/ngx_http_core_module.html#client_body_temp
> > _path
> В смысле, значение наверняка не задано в конфигурации совсем и тогда
> используется заданное при сборке значение, а внутри контейнера нет
> соответствующего каталога. Проще всего задать в конфигурации правильный
> путь куда-нибудь в /tmp или в /var/tmp, смотря что есть в контейнере.

1) Речь не про сам NginX, а про NginX Unit (отдельный application server).
2) увы, и /tmp и /var/tmp там есть. И доступ у юнита туда, вроде, тоже есть.

From eugen на grosbein.net  Thu Jul 16 11:13:52 2020
From: eugen на grosbein.net (Eugene Grosbein)
Date: Thu, 16 Jul 2020 18:13:52 +0700
Subject: [Unit] [error] 28#39 *18 mkstemp() failed (2: No such file or
 directory)
In-Reply-To: <4502606.cZfUaBzzB3@note>
References: <1612848.uBFMFrglHY@note>
 <9483f35f-5e18-4d28-84c7-ca2b9d346ada@grosbein.net>
 <efc08902-af6b-8f59-e7f6-956e8935862e@grosbein.net> <4502606.cZfUaBzzB3@note>
Message-ID: <13396451-4c4d-c0df-4cc7-ba7e048cfff4@grosbein.net>

16.07.2020 17:52, Vadim A. Misbakh-Soloviov wrote:

>>> Похоже на некорректную настройку client_body_temp_path (несуществующий
>>> путь):
>>> https://nginx.org/ru/docs/http/ngx_http_core_module.html#client_body_temp
>>> _path
>> В смысле, значение наверняка не задано в конфигурации совсем и тогда
>> используется заданное при сборке значение, а внутри контейнера нет
>> соответствующего каталога. Проще всего задать в конфигурации правильный
>> путь куда-нибудь в /tmp или в /var/tmp, смотря что есть в контейнере.
> 
> 1) Речь не про сам NginX, а про NginX Unit (отдельный application server).

https://github.com/nginx/unit/commit/5296be0b82784eb90abc86339e6c16841e9a9727

> 2) увы, и /tmp и /var/tmp там есть. И доступ у юнита туда, вроде, тоже есть.

А в сборке дефолтом может быть какое-нибудь /run/shm/body_temp
Что мешает настроить и проверить?



From vbart на nginx.com  Thu Jul 16 15:02:48 2020
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Thu, 16 Jul 2020 18:02:48 +0300
Subject: [Unit] [error] 28#39 *18 mkstemp() failed (2: No such file or
 directory)
In-Reply-To: <1612848.uBFMFrglHY@note>
References: <1612848.uBFMFrglHY@note>
Message-ID: <5618127.lOV4Wx5bFT@vbart-laptop>

On Thursday, 16 July 2020 13:13:22 MSK Vadim A. Misbakh-Soloviov wrote:
> Здравствуйте, сообщество и уважаемые разработчики!
> На одном из проектов мы используем Docker-контейнеры с alpine linux, в которых 
> стоит Unit с питоно-модулем, а так же задеплоенное Django-приложение.
> 
> И вот уже на втором проекте мы сталкиваемся с ошибкой, процитированной в 
> заголовке при сохранении данных из админки джанго. Что интересно, данные 
> сохраняются в базу, и там вообще копеечный объём.
[..]

А откуда для алпайна пакет с юнитом взят?

Там вероятно неправильно задан --tmp путь (или вообще не задан и смотрит
по умолчанию в "tmp" внутри рабочей директории).

Можно переопределить на старте: unitd --tmp=/tmp


> P.S. как я вижу выше по коду, более глобальной причиной является то, что   
> (body_length > body_buffer_size).
> Однако, я что-то нигде в документации юнита не могу найти крутилку максимально 
> разрешённого body_buffer_size...


Оно не задокументировано пока, ибо есть вероятность,
что реализация будет изменяться:

{
    "settings": {
        "http": {
            "body_buffer_size": 16384
        }
    }
}

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

From nginx-forum на forum.nginx.org  Thu Jul 16 16:19:09 2020
From: nginx-forum на forum.nginx.org (bagas)
Date: Thu, 16 Jul 2020 12:19:09 -0400
Subject: =?UTF-8?B?0JrQsNC6INGA0LDRgdGB0YfQuNGC0LDRgtGMIHNzbCBidWZmZXIgc2l6ZQ==?=
Message-ID: <2fbe5d5909d97f8451605fb3d18e71df.NginxMailingListRussian@forum.nginx.org>

Добрый вечер.
Подскажите пожалуйста, как правильно рассчитать параметр ssl_buffer_size для
своего вэб проекта?
Версия nginx/1.18.0

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


From nginx на mva.name  Thu Jul 16 18:10:27 2020
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Fri, 17 Jul 2020 01:10:27 +0700
Subject: [Unit] [error] 28#39 *18 mkstemp() failed (2: No such file or
 directory)
In-Reply-To: <5618127.lOV4Wx5bFT@vbart-laptop>
References: <1612848.uBFMFrglHY@note> <5618127.lOV4Wx5bFT@vbart-laptop>
Message-ID: <5939021.xxFRWHgVgX@note>


> А откуда для алпайна пакет с юнитом взят?
> 

https://pkgs.alpinelinux.org/packages?name=unit*&branch=edge&arch=x86_64

> Там вероятно неправильно задан --tmp путь (или вообще не задан и смотрит
> по умолчанию в "tmp" внутри рабочей директории).
Именно так и оказалось :(

> Можно переопределить на старте: unitd --tmp=/tmp

Именно так и сделали, да. В враппере-запускалке указали вручную --tmp /tmp 
(без "=", впрочем, но работает и так)

> 
> Оно не задокументировано пока, ибо есть вероятность,
> что реализация будет изменяться:

Ну, было бы хорошо, если бы не менялась (ну, или по крайней мере, в лучшую 
сторону, а не в сторону пропадания крутилки) :)

Будем иметь в виду, спасибо! :)

From nginx-forum на forum.nginx.org  Fri Jul 17 09:38:17 2020
From: nginx-forum на forum.nginx.org (nkatsy)
Date: Fri, 17 Jul 2020 05:38:17 -0400
Subject: nginx add_header
Message-ID: <b847342832c3ec78803ff0b9aadd34f1.NginxMailingListRussian@forum.nginx.org>

Добрый день.

В секции http есть есть следующие директивы:

--
    add_header X-Frame-Options 'SAMEORIGIN';
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Content-Type-Options nosniff;
--

Которые почему-то не наследуются для https-версии сайта.
Для http - работает.
Если эти директивы добавить в https секцию. 
Все работает.
В чем может быть проблема?
--

Спасибо.

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


From chipitsine на gmail.com  Fri Jul 17 10:17:06 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 17 Jul 2020 15:17:06 +0500
Subject: nginx add_header
In-Reply-To: <b847342832c3ec78803ff0b9aadd34f1.NginxMailingListRussian@forum.nginx.org>
References: <b847342832c3ec78803ff0b9aadd34f1.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQGce8P9ouYGYvCxJdDN_VW_kpks+thhJyQ+EOd9peHGEg@mail.gmail.com>

Наследуются. Но если на уровне server есть add_header, то все директивы
уровня выше игнорятся

On Fri, Jul 17, 2020, 2:38 PM nkatsy <nginx-forum на forum.nginx.org> wrote:

> Добрый день.
>
> В секции http есть есть следующие директивы:
>
> --
>     add_header X-Frame-Options 'SAMEORIGIN';
>     add_header X-XSS-Protection "1; mode=block";
>     add_header X-Content-Type-Options nosniff;
> --
>
> Которые почему-то не наследуются для https-версии сайта.
> Для http - работает.
> Если эти директивы добавить в https секцию.
> Все работает.
> В чем может быть проблема?
> --
>
> Спасибо.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288741,288741#msg-288741
>
> _______________________________________________
> 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/20200717/8aa52875/attachment.htm>

From mdounin на mdounin.ru  Fri Jul 17 11:04:39 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Fri, 17 Jul 2020 14:04:39 +0300
Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0YHRgdGH0LjRgtCw0YLRjCBzc2wgYnVmZmVyIHNpemU=?=
In-Reply-To: <2fbe5d5909d97f8451605fb3d18e71df.NginxMailingListRussian@forum.nginx.org>
References: <2fbe5d5909d97f8451605fb3d18e71df.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200717110439.GG12747@mdounin.ru>

Hello!

On Thu, Jul 16, 2020 at 12:19:09PM -0400, bagas wrote:

> Добрый вечер.
> Подскажите пожалуйста, как правильно рассчитать параметр ssl_buffer_size для
> своего вэб проекта?
> Версия nginx/1.18.0

Лучше всего - не трогать, если нет чёткого понимания зачем это вам 
нужно.

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

From nginx-forum на forum.nginx.org  Fri Jul 17 12:41:49 2020
From: nginx-forum на forum.nginx.org (bagas)
Date: Fri, 17 Jul 2020 08:41:49 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0YHRgdGH0LjRgtCw0YLRjCBzc2wgYnVmZmVyIHNpemU=?=
In-Reply-To: <20200717110439.GG12747@mdounin.ru>
References: <20200717110439.GG12747@mdounin.ru>
Message-ID: <34860a3dd91faacc79a6fbc74fd918c0.NginxMailingListRussian@forum.nginx.org>

Понимание для чего нужно есть.
Слышал для улучшения отзывчивости сайта нужно уменьшать, но вот как
вычислить?

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


From chipitsine на gmail.com  Fri Jul 17 13:07:01 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 17 Jul 2020 18:07:01 +0500
Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0YHRgdGH0LjRgtCw0YLRjCBzc2wgYnVmZmVyIHNpemU=?=
In-Reply-To: <34860a3dd91faacc79a6fbc74fd918c0.NginxMailingListRussian@forum.nginx.org>
References: <20200717110439.GG12747@mdounin.ru>
 <34860a3dd91faacc79a6fbc74fd918c0.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQHcdQh1mdNmTLshBP4kciH7ZgyYXnU7Eu1iiAFjKbBurA@mail.gmail.com>

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

пт, 17 июл. 2020 г. в 17:41, bagas <nginx-forum на forum.nginx.org>:

> Понимание для чего нужно есть.
> Слышал для улучшения отзывчивости сайта нужно уменьшать, но вот как
> вычислить?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288743,288744#msg-288744
>
> _______________________________________________
> 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/20200717/7b7b33f2/attachment.htm>

From nginx-forum на forum.nginx.org  Fri Jul 17 16:53:55 2020
From: nginx-forum на forum.nginx.org (bagas)
Date: Fri, 17 Jul 2020 12:53:55 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDRgNCw0YHRgdGH0LjRgtCw0YLRjCBzc2wgYnVmZmVyIHNpemU=?=
In-Reply-To: <CAFHpkQHcdQh1mdNmTLshBP4kciH7ZgyYXnU7Eu1iiAFjKbBurA@mail.gmail.com>
References: <CAFHpkQHcdQh1mdNmTLshBP4kciH7ZgyYXnU7Eu1iiAFjKbBurA@mail.gmail.com>
Message-ID: <b8cc85bc03857bd3d51583d88f5c06e3.NginxMailingListRussian@forum.nginx.org>

Ясно, пока кручу настройки на тестовом сервере.

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


From nginx-forum на forum.nginx.org  Fri Jul 17 20:23:02 2020
From: nginx-forum на forum.nginx.org (nkatsy)
Date: Fri, 17 Jul 2020 16:23:02 -0400
Subject: nginx add_header
In-Reply-To: <CAFHpkQGce8P9ouYGYvCxJdDN_VW_kpks+thhJyQ+EOd9peHGEg@mail.gmail.com>
References: <CAFHpkQGce8P9ouYGYvCxJdDN_VW_kpks+thhJyQ+EOd9peHGEg@mail.gmail.com>
Message-ID: <17f5468fc50fc1624078c2c416836a81.NginxMailingListRussian@forum.nginx.org>

Хм, неожиданно.  Но так и есть.
В server был другой add_header.
Не логичнее ли было бы наследовать, с http, то что не оговоренно в server?

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


From nginx-forum на forum.nginx.org  Fri Jul 17 20:26:09 2020
From: nginx-forum на forum.nginx.org (nkatsy)
Date: Fri, 17 Jul 2020 16:26:09 -0400
Subject: nginx add_header
In-Reply-To: <17f5468fc50fc1624078c2c416836a81.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQGce8P9ouYGYvCxJdDN_VW_kpks+thhJyQ+EOd9peHGEg@mail.gmail.com>
 <17f5468fc50fc1624078c2c416836a81.NginxMailingListRussian@forum.nginx.org>
Message-ID: <069a7e03dbde412f37735e43372590f0.NginxMailingListRussian@forum.nginx.org>

Например, в моем конкретном случае в server это 
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains;
preload"; 
для https. Который вставлять в http-секцию неправильно.

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


From chipitsine на gmail.com  Fri Jul 17 20:34:26 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sat, 18 Jul 2020 01:34:26 +0500
Subject: nginx add_header
In-Reply-To: <17f5468fc50fc1624078c2c416836a81.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQGce8P9ouYGYvCxJdDN_VW_kpks+thhJyQ+EOd9peHGEg@mail.gmail.com>
 <17f5468fc50fc1624078c2c416836a81.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQEx1=qDyzFOTOz=Phu-xbq2mQirBG_JUh36VfFB3aV7Ww@mail.gmail.com>

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

On Sat, Jul 18, 2020, 1:23 AM nkatsy <nginx-forum на forum.nginx.org> wrote:

> Хм, неожиданно.  Но так и есть.
> В server был другой add_header.
> Не логичнее ли было бы наследовать, с http, то что не оговоренно в server?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288741,288751#msg-288751
>
> _______________________________________________
> 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/20200718/ae14c7ee/attachment.htm>

From nginx-forum на forum.nginx.org  Tue Jul 21 07:38:17 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Tue, 21 Jul 2020 03:38:17 -0400
Subject: =?UTF-8?B?0JrQsNC6INC/0YDQsNCy0LjQu9GM0L3QviDRgdC60LvQtdC40YLRjCB3d3cg0L0=?=
 =?UTF-8?B?0LAg0LHQtdC3IHd3dz8=?=
Message-ID: <b0c3baea7cf5ea5c608647938c729196.NginxMailingListRussian@forum.nginx.org>

Сейчас у меня такие настройки:

server {
  listen 80;
  server_name www.site.com site.com;

  location / {
    return 301 https://site.com$request_uri;
  }
}

server {
  listen 443 default ssl;
  server_name www.site.com site.com;
  if ($host ~* ^www\.(.+)$) {
    rewrite ^ https://site.com$request_uri permanent;
  }
  rewrite ^/(.*)/$ /$1 permanent;
  ...
}

if ($host ~* ^www\.(.+)$) { - не срабатывает.

пробовал еще перед server { listen 443 default ssl; ... }, но тоже не
срабатывает:

server {
  listen 443 ssl;
  server_name www.site.com;
  return 301 https://site.com$request_uri;
}

Куда смотреть?

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


From red-fox0 на ya.ru  Tue Jul 21 08:50:03 2020
From: red-fox0 на ya.ru (fox)
Date: Tue, 21 Jul 2020 15:50:03 +0700
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LDQstC40LvRjNC90L4g0YHQutC70LXQuNGC0Ywgd3d3?=
 =?UTF-8?B?INC90LAg0LHQtdC3IHd3dz8=?=
In-Reply-To: <b0c3baea7cf5ea5c608647938c729196.NginxMailingListRussian@forum.nginx.org>
References: <b0c3baea7cf5ea5c608647938c729196.NginxMailingListRussian@forum.nginx.org>
Message-ID: <11f03344-a5b8-77da-3e69-fed3273bed66@ya.ru>

У меня так работает:

server {
  listen 80;
  listen 443 ssl http2;
  server_name www.site.com;
  return 301 https://site.com$request_uri;
}

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

server {
  listen 443 ssl http2;
  server_name site.com;
  #...
}


On 21.07.2020 14:38, akoval wrote:
> Сейчас у меня такие настройки:
> 
> server {
>   listen 80;
>   server_name www.site.com site.com;
> 
>   location / {
>     return 301 https://site.com$request_uri;
>   }
> }
> 
> server {
>   listen 443 default ssl;
>   server_name www.site.com site.com;
>   if ($host ~* ^www\.(.+)$) {
>     rewrite ^ https://site.com$request_uri permanent;
>   }
>   rewrite ^/(.*)/$ /$1 permanent;
>   ...
> }
> 
> if ($host ~* ^www\.(.+)$) { - не срабатывает.
> 
> пробовал еще перед server { listen 443 default ssl; ... }, но тоже не
> срабатывает:
> 
> server {
>   listen 443 ssl;
>   server_name www.site.com;
>   return 301 https://site.com$request_uri;
> }
> 
> Куда смотреть?
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288770,288770#msg-288770
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 


From red-fox0 на ya.ru  Tue Jul 21 08:52:26 2020
From: red-fox0 на ya.ru (fox)
Date: Tue, 21 Jul 2020 15:52:26 +0700
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LDQstC40LvRjNC90L4g0YHQutC70LXQuNGC0Ywgd3d3?=
 =?UTF-8?B?INC90LAg0LHQtdC3IHd3dz8=?=
In-Reply-To: <11f03344-a5b8-77da-3e69-fed3273bed66@ya.ru>
References: <b0c3baea7cf5ea5c608647938c729196.NginxMailingListRussian@forum.nginx.org>
 <11f03344-a5b8-77da-3e69-fed3273bed66@ya.ru>
Message-ID: <3a9853ee-d4cb-b002-7e73-14b8ea41fb33@ya.ru>

Так чуть лучше:

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

server {
  listen 443 ssl http2;
  server_name www.site.com;
  return 301 https://site.com$request_uri;
}

server {
  listen 443 ssl http2;
  server_name site.com;
  #...
}


On 21.07.2020 15:50, fox wrote:
> У меня так работает:
> 
> server {
>   listen 80;
>   listen 443 ssl http2;
>   server_name www.site.com;
>   return 301 https://site.com$request_uri;
> }
> 
> server {
>   listen 80;
>   server_name site.com;
>   return 301 https://site.com$request_uri;
> }
> 
> server {
>   listen 443 ssl http2;
>   server_name site.com;
>   #...
> }
> 
> 
> On 21.07.2020 14:38, akoval wrote:
>> Сейчас у меня такие настройки:
>>
>> server {
>>   listen 80;
>>   server_name www.site.com site.com;
>>
>>   location / {
>>     return 301 https://site.com$request_uri;
>>   }
>> }
>>
>> server {
>>   listen 443 default ssl;
>>   server_name www.site.com site.com;
>>   if ($host ~* ^www\.(.+)$) {
>>     rewrite ^ https://site.com$request_uri permanent;
>>   }
>>   rewrite ^/(.*)/$ /$1 permanent;
>>   ...
>> }
>>
>> if ($host ~* ^www\.(.+)$) { - не срабатывает.
>>
>> пробовал еще перед server { listen 443 default ssl; ... }, но тоже не
>> срабатывает:
>>
>> server {
>>   listen 443 ssl;
>>   server_name www.site.com;
>>   return 301 https://site.com$request_uri;
>> }
>>
>> Куда смотреть?
>>
>> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288770,288770#msg-288770
>>
>> _______________________________________________
>> 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
> 


From root на dl.sm.ua  Tue Jul 21 09:19:16 2020
From: root на dl.sm.ua (Dmytro Lavryk)
Date: Tue, 21 Jul 2020 12:19:16 +0300
Subject: =?UTF-8?B?0JLRltC00L/QvtCy0ZbQtNGMOiDQmtCw0Log0L/RgNCw0LLQuNC70YzQvdC+INGB?=
 =?UTF-8?B?0LrQu9C10LjRgtGMIHd3dyDQvdCwINCx0LXQtyB3d3c/?=
In-Reply-To: <b0c3baea7cf5ea5c608647938c729196.NginxMailingListRussian@forum.nginx.org>
References: <b0c3baea7cf5ea5c608647938c729196.NginxMailingListRussian@forum.nginx.org>
Message-ID: <17370ab89c9.bb7c5d44357056.7071151353191146981@dl.sm.ua>

Как пример:

server {

    server_name serer.name www.server.name;

    listen 80;

    listen 443 ssl http2;



    if ($host != "server.name") {

        rewrite ^   https://server.name$request_uri? permanent;

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

From mdounin на mdounin.ru  Tue Jul 21 13:31:02 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 21 Jul 2020 16:31:02 +0300
Subject: nginx add_header
In-Reply-To: <17f5468fc50fc1624078c2c416836a81.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQGce8P9ouYGYvCxJdDN_VW_kpks+thhJyQ+EOd9peHGEg@mail.gmail.com>
 <17f5468fc50fc1624078c2c416836a81.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200721133102.GI12747@mdounin.ru>

Hello!

On Fri, Jul 17, 2020 at 04:23:02PM -0400, nkatsy wrote:

> Хм, неожиданно.  Но так и есть.
> В server был другой add_header.
> Не логичнее ли было бы наследовать, с http, то что не оговоренно в server?

Именно так и делается - если директивы add_header не оговорены в 
секции server, то они наследуются.  Если оговорены - не 
наследуются.

Вы же, судя по всему, под "не оговорено" понимаете попытки по 
каким-то правилам "склеить" директивы add_header с уровня http и 
директивы add_header с уровня server.  Так не логичнее как минимум 
по двум причинам:

1. С точки зрения кода проще и логичнее наследовать значение или 
массив значений целиком, а не пытаться "склеить" комбинацию из 
разных массивов.  Тем более, что завтра окажется, что нужен и 
"add_header Set-Cookie foo=1;" с уровня http, и "add_header 
Set-Cookie bar=2;" с уровня server, а вот "add_header Set-Cookie 
bazz=1;" с уровня http - не нужен, и как их правильно "склеивать" 
совершенно непонятно.

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

Поэтому приблизительно все директивы в nginx'е работают по одной и 
той же простой схеме: если директива задана на текущем уровне, то 
она не наследуется, если не задана - то наследуется.  Исключения - 
отдельные директивы, которые вообще не наследуются.

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

Кроме того, я бы тут ещё упомянул вопрос масштабируемости 
конфигурации.  Игорь подробно рассказывал об этом тут:

https://youtu.be/jf3wIN-FwW4

Текущая схема минимизирует как число мест, в которые надо 
смотреть, чтобы понять конфигурацию (скажем, если на уровне 
locationn есть директива add_header - можно быть уверенным, что 
соответствующие директивы с других уровней на заголовки не 
повлияют), так и возможные последствия от изменения конфигурации.

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

From slw на zxy.spb.ru  Tue Jul 21 15:05:22 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Tue, 21 Jul 2020 18:05:22 +0300
Subject: =?UTF-8?B?YXV0aF9yZXF1ZXN0INC4INC/0LXRgNC10LzQtdC90L3Ri9C1INCyIHByb3h5X3Bh?=
 =?UTF-8?B?c3M=?=
Message-ID: <20200721150522.GM2015@zxy.spb.ru>

А я правильно понимаю, что в блоке proxy_pass который активируется по
auth_request никакие переменые от rewrite и/или $arg_ использовать не удастся?

From constantine на mellodesign.ru  Tue Jul 21 15:08:53 2020
From: constantine на mellodesign.ru (=?utf-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0KLQutCw0YfQtdC90LrQvg==?=)
Date: Tue, 21 Jul 2020 19:08:53 +0400
Subject: =?UTF-8?B?UmU6IGF1dGhfcmVxdWVzdCDQuCDQv9C10YDQtdC80LXQvdC90YvQtSDQsiBwcm94?=
 =?UTF-8?B?eV9wYXNz?=
In-Reply-To: <20200721150522.GM2015@zxy.spb.ru>
References: <20200721150522.GM2015@zxy.spb.ru>
Message-ID: <B6DBD541-87E4-44B9-80D0-38564D7B2C79@mellodesign.ru>


> 21 июля 2020 г., в 19:05, Slawa Olhovchenkov <slw на zxy.spb.ru> написал(а):
> 
> А я правильно понимаю, что в блоке proxy_pass который активируется по
> auth_request никакие переменые от rewrite и/или $arg_ использовать не удастся?
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Можно. Я использую там $request_uri;

From slw на zxy.spb.ru  Tue Jul 21 15:27:19 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Tue, 21 Jul 2020 18:27:19 +0300
Subject: =?UTF-8?B?UmU6IGF1dGhfcmVxdWVzdCDQuCDQv9C10YDQtdC80LXQvdC90YvQtSDQsiBwcm94?=
 =?UTF-8?B?eV9wYXNz?=
In-Reply-To: <B6DBD541-87E4-44B9-80D0-38564D7B2C79@mellodesign.ru>
References: <20200721150522.GM2015@zxy.spb.ru>
 <B6DBD541-87E4-44B9-80D0-38564D7B2C79@mellodesign.ru>
Message-ID: <20200721152719.GN2015@zxy.spb.ru>

On Tue, Jul 21, 2020 at 07:08:53PM +0400, Константин Ткаченко wrote:

> 
> > 21 июля 2020 г., в 19:05, Slawa Olhovchenkov <slw на zxy.spb.ru> написал(а):
> > 
> > А я правильно понимаю, что в блоке proxy_pass который активируется по
> > auth_request никакие переменые от rewrite и/или $arg_ использовать не удастся?
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru на nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> Можно. Я использую там $request_uri;

А $request_uri к какой категории относится -- rewrite или $arg_?

From mdounin на mdounin.ru  Tue Jul 21 17:13:12 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 21 Jul 2020 20:13:12 +0300
Subject: =?UTF-8?B?UmU6IGF1dGhfcmVxdWVzdCDQuCDQv9C10YDQtdC80LXQvdC90YvQtSDQsiBwcm94?=
 =?UTF-8?B?eV9wYXNz?=
In-Reply-To: <20200721150522.GM2015@zxy.spb.ru>
References: <20200721150522.GM2015@zxy.spb.ru>
Message-ID: <20200721171312.GM12747@mdounin.ru>

Hello!

On Tue, Jul 21, 2020 at 06:05:22PM +0300, Slawa Olhovchenkov wrote:

> А я правильно понимаю, что в блоке proxy_pass который активируется по
> auth_request никакие переменые от rewrite и/или $arg_ использовать не удастся?

Почему нет?  Ну то есть с переменными от модуля rewrite вообще 
никаких проблем быть не должно, а в части $arg_* важно понимать, 
что они будут не от исходного запроса, а от подзапроса 
аутентификации (и скорее всего пустые, ибо директива auth_request 
принимает URI без аргументов).

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

From slw на zxy.spb.ru  Tue Jul 21 17:22:50 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Tue, 21 Jul 2020 20:22:50 +0300
Subject: =?UTF-8?B?UmU6IGF1dGhfcmVxdWVzdCDQuCDQv9C10YDQtdC80LXQvdC90YvQtSDQsiBwcm94?=
 =?UTF-8?B?eV9wYXNz?=
In-Reply-To: <20200721171312.GM12747@mdounin.ru>
References: <20200721150522.GM2015@zxy.spb.ru>
 <20200721171312.GM12747@mdounin.ru>
Message-ID: <20200721172250.GO2015@zxy.spb.ru>

On Tue, Jul 21, 2020 at 08:13:12PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Tue, Jul 21, 2020 at 06:05:22PM +0300, Slawa Olhovchenkov wrote:
> 
> > А я правильно понимаю, что в блоке proxy_pass который активируется по
> > auth_request никакие переменые от rewrite и/или $arg_ использовать не удастся?
> 
> Почему нет?  Ну то есть с переменными от модуля rewrite вообще 

ну вот попытка сделать set (блоком выше и потом использовать
переменную) у меня как-то не сработала -- пусто.
а set -- это rewrite только в порфиль.

> никаких проблем быть не должно, а в части $arg_* важно понимать, 
> что они будут не от исходного запроса, а от подзапроса 
> аутентификации (и скорее всего пустые, ибо директива auth_request 
> принимает URI без аргументов).

Ах вот как.

From mdounin на mdounin.ru  Tue Jul 21 17:47:15 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 21 Jul 2020 20:47:15 +0300
Subject: =?UTF-8?B?UmU6IGF1dGhfcmVxdWVzdCDQuCDQv9C10YDQtdC80LXQvdC90YvQtSDQsiBwcm94?=
 =?UTF-8?B?eV9wYXNz?=
In-Reply-To: <20200721172250.GO2015@zxy.spb.ru>
References: <20200721150522.GM2015@zxy.spb.ru>
 <20200721171312.GM12747@mdounin.ru>
 <20200721172250.GO2015@zxy.spb.ru>
Message-ID: <20200721174715.GN12747@mdounin.ru>

Hello!

On Tue, Jul 21, 2020 at 08:22:50PM +0300, Slawa Olhovchenkov wrote:

> On Tue, Jul 21, 2020 at 08:13:12PM +0300, Maxim Dounin wrote:
> 
> > Hello!
> > 
> > On Tue, Jul 21, 2020 at 06:05:22PM +0300, Slawa Olhovchenkov wrote:
> > 
> > > А я правильно понимаю, что в блоке proxy_pass который активируется по
> > > auth_request никакие переменые от rewrite и/или $arg_ использовать не удастся?
> > 
> > Почему нет?  Ну то есть с переменными от модуля rewrite вообще 
> 
> ну вот попытка сделать set (блоком выше и потом использовать
> переменную) у меня как-то не сработала -- пусто.
> а set -- это rewrite только в порфиль.

Видимо, "как-то не сработала" по каким-то другим причинам.  
Скажем, если делать set на уровне server - то он потом ещё раз 
сделается в подзапросе, и результат может быть отличен от 
ожидаемого (особенно если этот set использует переменные $arg_*, 
которые в подзапросе будут иметь другие значения).

С какой-то такой конфигурацией работает без проблем:

    server {
        listen 8080;

        location / {
            set $foo $arg_foo;
            auth_request /auth;
        }

        location = /auth {
            if ($foo) {
                return 204; 
            }

            return 401;
        }
    }

$ curl -I http://127.0.0.1:8080/?foo=0
HTTP/1.1 401 Unauthorized
Server: nginx/1.19.1
Date: Tue, 21 Jul 2020 17:38:19 GMT
Content-Type: text/html
Content-Length: 179
Connection: keep-alive

$ curl -I http://127.0.0.1:8080/?foo=1
HTTP/1.1 200 OK
Server: nginx/1.19.1
Date: Tue, 21 Jul 2020 17:38:22 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 18 Jul 2017 14:42:47 GMT
Connection: keep-alive
ETag: "596e1e67-264"
Accept-Ranges: bytes

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

From slw на zxy.spb.ru  Tue Jul 21 18:22:36 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Tue, 21 Jul 2020 21:22:36 +0300
Subject: =?UTF-8?B?UmU6IGF1dGhfcmVxdWVzdCDQuCDQv9C10YDQtdC80LXQvdC90YvQtSDQsiBwcm94?=
 =?UTF-8?B?eV9wYXNz?=
In-Reply-To: <20200721174715.GN12747@mdounin.ru>
References: <20200721150522.GM2015@zxy.spb.ru>
 <20200721171312.GM12747@mdounin.ru>
 <20200721172250.GO2015@zxy.spb.ru>
 <20200721174715.GN12747@mdounin.ru>
Message-ID: <20200721182236.GP2015@zxy.spb.ru>

On Tue, Jul 21, 2020 at 08:47:15PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Tue, Jul 21, 2020 at 08:22:50PM +0300, Slawa Olhovchenkov wrote:
> 
> > On Tue, Jul 21, 2020 at 08:13:12PM +0300, Maxim Dounin wrote:
> > 
> > > Hello!
> > > 
> > > On Tue, Jul 21, 2020 at 06:05:22PM +0300, Slawa Olhovchenkov wrote:
> > > 
> > > > А я правильно понимаю, что в блоке proxy_pass который активируется по
> > > > auth_request никакие переменые от rewrite и/или $arg_ использовать не удастся?
> > > 
> > > Почему нет?  Ну то есть с переменными от модуля rewrite вообще 
> > 
> > ну вот попытка сделать set (блоком выше и потом использовать
> > переменную) у меня как-то не сработала -- пусто.
> > а set -- это rewrite только в порфиль.
> 
> Видимо, "как-то не сработала" по каким-то другим причинам.  
> Скажем, если делать set на уровне server - то он потом ещё раз 
> сделается в подзапросе, и результат может быть отличен от 
> ожидаемого (особенно если этот set использует переменные $arg_*, 
> которые в подзапросе будут иметь другие значения).

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

From slw на zxy.spb.ru  Wed Jul 22 10:05:43 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Wed, 22 Jul 2020 13:05:43 +0300
Subject: =?UTF-8?B?UmU6IGF1dGhfcmVxdWVzdCDQuCDQv9C10YDQtdC80LXQvdC90YvQtSDQsiBwcm94?=
 =?UTF-8?B?eV9wYXNz?=
In-Reply-To: <20200721182236.GP2015@zxy.spb.ru>
References: <20200721150522.GM2015@zxy.spb.ru>
 <20200721171312.GM12747@mdounin.ru>
 <20200721172250.GO2015@zxy.spb.ru>
 <20200721174715.GN12747@mdounin.ru>
 <20200721182236.GP2015@zxy.spb.ru>
Message-ID: <20200722100543.GQ2015@zxy.spb.ru>

On Tue, Jul 21, 2020 at 09:22:36PM +0300, Slawa Olhovchenkov wrote:

> On Tue, Jul 21, 2020 at 08:47:15PM +0300, Maxim Dounin wrote:
> 
> > Hello!
> > 
> > On Tue, Jul 21, 2020 at 08:22:50PM +0300, Slawa Olhovchenkov wrote:
> > 
> > > On Tue, Jul 21, 2020 at 08:13:12PM +0300, Maxim Dounin wrote:
> > > 
> > > > Hello!
> > > > 
> > > > On Tue, Jul 21, 2020 at 06:05:22PM +0300, Slawa Olhovchenkov wrote:
> > > > 
> > > > > А я правильно понимаю, что в блоке proxy_pass который активируется по
> > > > > auth_request никакие переменые от rewrite и/или $arg_ использовать не удастся?
> > > > 
> > > > Почему нет?  Ну то есть с переменными от модуля rewrite вообще 
> > > 
> > > ну вот попытка сделать set (блоком выше и потом использовать
> > > переменную) у меня как-то не сработала -- пусто.
> > > а set -- это rewrite только в порфиль.
> > 
> > Видимо, "как-то не сработала" по каким-то другим причинам.  
> > Скажем, если делать set на уровне server - то он потом ещё раз 
> > сделается в подзапросе, и результат может быть отличен от 
> > ожидаемого (особенно если этот set использует переменные $arg_*, 
> > которые в подзапросе будут иметь другие значения).
> 
> Возможно.
> Сейчас еще раз перепрверил -- таки работает.

А rewrite внутри location с auth_request срабатывает до или после
сабреквеста?
можно ли в нем использовать результат  auth_request_set?

From nginx-forum на forum.nginx.org  Wed Jul 22 12:20:57 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Wed, 22 Jul 2020 08:20:57 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LDQstC40LvRjNC90L4g0YHQutC70LXQuNGC0Ywgd3d3?=
 =?UTF-8?B?INC90LAg0LHQtdC3IHd3dz8=?=
In-Reply-To: <3a9853ee-d4cb-b002-7e73-14b8ea41fb33@ya.ru>
References: <3a9853ee-d4cb-b002-7e73-14b8ea41fb33@ya.ru>
Message-ID: <38b076eb406447cc9719ed8263d430b3.NginxMailingListRussian@forum.nginx.org>

при таком конфиге у меня www.site.com редиректит на https://www.site.com...

This site can’t be reached www.site.com’s server IP address could not be
found.
DNS_PROBE_FINISHED_NXDOMAIN

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


From nginx-forum на forum.nginx.org  Wed Jul 22 12:39:06 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Wed, 22 Jul 2020 08:39:06 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LDQstC40LvRjNC90L4g0YHQutC70LXQuNGC0Ywgd3d3?=
 =?UTF-8?B?INC90LAg0LHQtdC3IHd3dz8=?=
In-Reply-To: <38b076eb406447cc9719ed8263d430b3.NginxMailingListRussian@forum.nginx.org>
References: <3a9853ee-d4cb-b002-7e73-14b8ea41fb33@ya.ru>
 <38b076eb406447cc9719ed8263d430b3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <75c3c53141969bfcc2eff98265a9ee52.NginxMailingListRussian@forum.nginx.org>

получаеться мой серевер не пингуеться... это в настройках nginx'а надо
что-то прописать?

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


From nginx-forum на forum.nginx.org  Wed Jul 22 12:47:42 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Wed, 22 Jul 2020 08:47:42 -0400
Subject: =?UTF-8?B?UmU6IFNTTCDQtNC70Y8gSUUgOA==?=
In-Reply-To: <CAFHpkQFVhTMnMWXw8pCUXpup29OycNDstw1oiT=QqikVBB4qjA@mail.gmail.com>
References: <CAFHpkQFVhTMnMWXw8pCUXpup29OycNDstw1oiT=QqikVBB4qjA@mail.gmail.com>
Message-ID: <b84633129e8767b5c4cb315d8e51b28c.NginxMailingListRussian@forum.nginx.org>

С первоначальным сайтом, о котором шла речь в первом посте дело затянулось,
вот адрес другого ogtrk.ru , где можно увидеть точно такую же проблему.
Напомню, сайт не открывается в IE8 на WinXP SP3 со всеми установленными
обновлениями, хотя шифр DES-CBC3-SHA в конфиге присутствует.

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


From red-fox0 на ya.ru  Wed Jul 22 12:55:42 2020
From: red-fox0 на ya.ru (fox)
Date: Wed, 22 Jul 2020 19:55:42 +0700
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LDQstC40LvRjNC90L4g0YHQutC70LXQuNGC0Ywgd3d3?=
 =?UTF-8?B?INC90LAg0LHQtdC3IHd3dz8=?=
In-Reply-To: <75c3c53141969bfcc2eff98265a9ee52.NginxMailingListRussian@forum.nginx.org>
References: <3a9853ee-d4cb-b002-7e73-14b8ea41fb33@ya.ru>
 <38b076eb406447cc9719ed8263d430b3.NginxMailingListRussian@forum.nginx.org>
 <75c3c53141969bfcc2eff98265a9ee52.NginxMailingListRussian@forum.nginx.org>
Message-ID: <811794be-3113-6a10-868f-051f3580445a@ya.ru>

В DNS-е домен/домены прописать.


22.07.2020 19:39, akoval пишет:
> получаеться мой серевер не пингуеться... это в настройках nginx'а надо
> что-то прописать?
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288770,288799#msg-288799
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 


From red-fox0 на ya.ru  Wed Jul 22 13:07:11 2020
From: red-fox0 на ya.ru (fox)
Date: Wed, 22 Jul 2020 20:07:11 +0700
Subject: =?UTF-8?B?UmU6IFNTTCDQtNC70Y8gSUUgOA==?=
In-Reply-To: <b84633129e8767b5c4cb315d8e51b28c.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQFVhTMnMWXw8pCUXpup29OycNDstw1oiT=QqikVBB4qjA@mail.gmail.com>
 <b84633129e8767b5c4cb315d8e51b28c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <5d747f31-1e68-ef59-b4e8-c42c1ae8f020@ya.ru>

Не знаю, чья ошибка: моя или сервера:

$ openssl s_client -cipher DES-CBC3-SHA -tls1 -connect ogtrk.ru:443
CONNECTED(00000005)
140423953981888:error:141A90B5:SSL routines:ssl_cipher_list_to_bytes:no
ciphers available:../ssl/statem/statem_clnt.c:3786:No ciphers enabled
for max supported SSL/TLS version
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 7 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1595423155
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---


22.07.2020 19:47, grey пишет:
> С первоначальным сайтом, о котором шла речь в первом посте дело затянулось,
> вот адрес другого ogtrk.ru , где можно увидеть точно такую же проблему.
> Напомню, сайт не открывается в IE8 на WinXP SP3 со всеми установленными
> обновлениями, хотя шифр DES-CBC3-SHA в конфиге присутствует.
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288640,288801#msg-288801
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 


From slw на zxy.spb.ru  Wed Jul 22 13:27:58 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Wed, 22 Jul 2020 16:27:58 +0300
Subject: =?UTF-8?Q?rewrite_=D0=B8_ngx=5Faws=5Fauth?=
Message-ID: <20200722132758.GR2015@zxy.spb.ru>

Пытаюсь подружить rewrite и ngx_aws_auth и выходит что-то странное.

в конфигурации локейшена у меня

            rewrite /(.*) /$host/$1;
            rewrite /([^.]+)[^/]+/(.*) /$1/$2 break;
	    aws_sign;

В дебаге видно что rewrite uri меняет, а ngx_aws_auth получает
немодифицированный uri.

если в локейшине написать if -- ngx_aws_auth вообще не срабатывает
(хотя тут я могу догадаться что он не наследуется).

Отсюда вопросы:

что за фигня?
что происходит?
какую переменную на самом деле меняет rewrite?


			

From mdounin на mdounin.ru  Wed Jul 22 13:41:26 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 22 Jul 2020 16:41:26 +0300
Subject: =?UTF-8?B?UmU6IGF1dGhfcmVxdWVzdCDQuCDQv9C10YDQtdC80LXQvdC90YvQtSDQsiBwcm94?=
 =?UTF-8?B?eV9wYXNz?=
In-Reply-To: <20200722100543.GQ2015@zxy.spb.ru>
References: <20200721150522.GM2015@zxy.spb.ru>
 <20200721171312.GM12747@mdounin.ru>
 <20200721172250.GO2015@zxy.spb.ru>
 <20200721174715.GN12747@mdounin.ru>
 <20200721182236.GP2015@zxy.spb.ru>
 <20200722100543.GQ2015@zxy.spb.ru>
Message-ID: <20200722134126.GP12747@mdounin.ru>

Hello!

On Wed, Jul 22, 2020 at 01:05:43PM +0300, Slawa Olhovchenkov wrote:

> On Tue, Jul 21, 2020 at 09:22:36PM +0300, Slawa Olhovchenkov wrote:
> 
> > On Tue, Jul 21, 2020 at 08:47:15PM +0300, Maxim Dounin wrote:
> > 
> > > Hello!
> > > 
> > > On Tue, Jul 21, 2020 at 08:22:50PM +0300, Slawa Olhovchenkov wrote:
> > > 
> > > > On Tue, Jul 21, 2020 at 08:13:12PM +0300, Maxim Dounin wrote:
> > > > 
> > > > > Hello!
> > > > > 
> > > > > On Tue, Jul 21, 2020 at 06:05:22PM +0300, Slawa Olhovchenkov wrote:
> > > > > 
> > > > > > А я правильно понимаю, что в блоке proxy_pass который активируется по
> > > > > > auth_request никакие переменые от rewrite и/или $arg_ использовать не удастся?
> > > > > 
> > > > > Почему нет?  Ну то есть с переменными от модуля rewrite вообще 
> > > > 
> > > > ну вот попытка сделать set (блоком выше и потом использовать
> > > > переменную) у меня как-то не сработала -- пусто.
> > > > а set -- это rewrite только в порфиль.
> > > 
> > > Видимо, "как-то не сработала" по каким-то другим причинам.  
> > > Скажем, если делать set на уровне server - то он потом ещё раз 
> > > сделается в подзапросе, и результат может быть отличен от 
> > > ожидаемого (особенно если этот set использует переменные $arg_*, 
> > > которые в подзапросе будут иметь другие значения).
> > 
> > Возможно.
> > Сейчас еще раз перепрверил -- таки работает.
> 
> А rewrite внутри location с auth_request срабатывает до или после
> сабреквеста?
> можно ли в нем использовать результат  auth_request_set?

Rewrite - это часть процедура выбора конфигурации, а 
auth_request/auth_basic/access - ограничение доступа к выбранной 
конфигурации.   Соответственно rewrite отрабатывает раньше, и 
использовать результат auth_request_set в нём нельзя.

Результат auth_request_set можно, скажем, передать на бекенд через 
proxy_set_header.  Или выбрать бэкенд в соответствии с.  Ну или 
просто записать в лог.

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

From chipitsine на gmail.com  Wed Jul 22 14:05:32 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 22 Jul 2020 19:05:32 +0500
Subject: =?UTF-8?B?UmU6IFNTTCDQtNC70Y8gSUUgOA==?=
In-Reply-To: <5d747f31-1e68-ef59-b4e8-c42c1ae8f020@ya.ru>
References: <CAFHpkQFVhTMnMWXw8pCUXpup29OycNDstw1oiT=QqikVBB4qjA@mail.gmail.com>
 <b84633129e8767b5c4cb315d8e51b28c.NginxMailingListRussian@forum.nginx.org>
 <5d747f31-1e68-ef59-b4e8-c42c1ae8f020@ya.ru>
Message-ID: <CAFHpkQH5fRABJAJkAKg7UxSskPogfKeOWDw_C=gCcOO+JH4wSg@mail.gmail.com>

ср, 22 июл. 2020 г. в 18:07, fox <red-fox0 на ya.ru>:

> Не знаю, чья ошибка: моя или сервера:
>
> $ openssl s_client -cipher DES-CBC3-SHA -tls1 -connect ogtrk.ru:443


https://www.ssllabs.com/ssltest/analyze.html?d=ogtrk.ru

действительно, IE8 не работает.
чуть позже покопаюсь более детально



>
> CONNECTED(00000005)
> 140423953981888:error:141A90B5:SSL routines:ssl_cipher_list_to_bytes:no
> ciphers available:../ssl/statem/statem_clnt.c:3786:No ciphers enabled
> for max supported SSL/TLS version
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 7 bytes
> Verification: OK
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
>     Protocol  : TLSv1
>     Cipher    : 0000
>     Session-ID:
>     Session-ID-ctx:
>     Master-Key:
>     PSK identity: None
>     PSK identity hint: None
>     SRP username: None
>     Start Time: 1595423155
>     Timeout   : 7200 (sec)
>     Verify return code: 0 (ok)
>     Extended master secret: no
> ---
>
>
> 22.07.2020 19:47, grey пишет:
> > С первоначальным сайтом, о котором шла речь в первом посте дело
> затянулось,
> > вот адрес другого ogtrk.ru , где можно увидеть точно такую же проблему.
> > Напомню, сайт не открывается в IE8 на WinXP SP3 со всеми установленными
> > обновлениями, хотя шифр DES-CBC3-SHA в конфиге присутствует.
> >
> > Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288640,288801#msg-288801
> >
> > _______________________________________________
> > 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/20200722/af73602b/attachment-0001.htm>

From mdounin на mdounin.ru  Wed Jul 22 14:07:20 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 22 Jul 2020 17:07:20 +0300
Subject: =?UTF-8?Q?Re=3A_rewrite_=D0=B8_ngx=5Faws=5Fauth?=
In-Reply-To: <20200722132758.GR2015@zxy.spb.ru>
References: <20200722132758.GR2015@zxy.spb.ru>
Message-ID: <20200722140720.GQ12747@mdounin.ru>

Hello!

On Wed, Jul 22, 2020 at 04:27:58PM +0300, Slawa Olhovchenkov wrote:

> Пытаюсь подружить rewrite и ngx_aws_auth и выходит что-то странное.
> 
> в конфигурации локейшена у меня
> 
>             rewrite /(.*) /$host/$1;
>             rewrite /([^.]+)[^/]+/(.*) /$1/$2 break;
> 	    aws_sign;
> 
> В дебаге видно что rewrite uri меняет, а ngx_aws_auth получает
> немодифицированный uri.
> 
> если в локейшине написать if -- ngx_aws_auth вообще не срабатывает
> (хотя тут я могу догадаться что он не наследуется).
> 
> Отсюда вопросы:
> 
> что за фигня?
> что происходит?
> какую переменную на самом деле меняет rewrite?

Заглянул в код этого ngx_aws_auth, всплакнул.

Всё правильно, работать не будет.  И не только после rewrite'а, но 
и в других непредсказуемых ситуациях - при наличии аргументов в 
запросе модуль лезет в r->uri_start, значение которого имее смысл 
только в момент парсинга URI и не гарантируется в остальное 
время[1][2].  

Лечится переписыванием модуля, чтобы использовал r->uri всегда.

[1] https://github.com/anomalizer/ngx_aws_auth/blob/master/aws_functions.h#L317
[2] http://hg.nginx.org/nginx/file/tip/src/http/ngx_http_request.h#l576

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

From slw на zxy.spb.ru  Wed Jul 22 14:14:34 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Wed, 22 Jul 2020 17:14:34 +0300
Subject: =?UTF-8?Q?Re=3A_rewrite_=D0=B8_ngx=5Faws=5Fauth?=
In-Reply-To: <20200722140720.GQ12747@mdounin.ru>
References: <20200722132758.GR2015@zxy.spb.ru>
 <20200722140720.GQ12747@mdounin.ru>
Message-ID: <20200722141434.GT2015@zxy.spb.ru>

On Wed, Jul 22, 2020 at 05:07:20PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Wed, Jul 22, 2020 at 04:27:58PM +0300, Slawa Olhovchenkov wrote:
> 
> > Пытаюсь подружить rewrite и ngx_aws_auth и выходит что-то странное.
> > 
> > в конфигурации локейшена у меня
> > 
> >             rewrite /(.*) /$host/$1;
> >             rewrite /([^.]+)[^/]+/(.*) /$1/$2 break;
> > 	    aws_sign;
> > 
> > В дебаге видно что rewrite uri меняет, а ngx_aws_auth получает
> > немодифицированный uri.
> > 
> > если в локейшине написать if -- ngx_aws_auth вообще не срабатывает
> > (хотя тут я могу догадаться что он не наследуется).
> > 
> > Отсюда вопросы:
> > 
> > что за фигня?
> > что происходит?
> > какую переменную на самом деле меняет rewrite?
> 
> Заглянул в код этого ngx_aws_auth, всплакнул.

да я уже неделю матерюсь. он еще и переменных где надо не понимает.

> Всё правильно, работать не будет.  И не только после rewrite'а, но 
> и в других непредсказуемых ситуациях - при наличии аргументов в 
> запросе модуль лезет в r->uri_start, значение которого имее смысл 
> только в момент парсинга URI и не гарантируется в остальное 
> время[1][2].  
> 
> Лечится переписыванием модуля, чтобы использовал r->uri всегда.

Ах вот оно как. Отлично, это из-за аргументов, а мне они нахрен не
нужны.
Отрезание помогает.

From nginx-forum на forum.nginx.org  Thu Jul 23 07:40:19 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Thu, 23 Jul 2020 03:40:19 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LDQstC40LvRjNC90L4g0YHQutC70LXQuNGC0Ywgd3d3?=
 =?UTF-8?B?INC90LAg0LHQtdC3IHd3dz8=?=
In-Reply-To: <811794be-3113-6a10-868f-051f3580445a@ya.ru>
References: <811794be-3113-6a10-868f-051f3580445a@ya.ru>
Message-ID: <eb82d2d2245cd3da943fc508d8a6d803.NginxMailingListRussian@forum.nginx.org>

В dns сервер прописан, то-есть ip сервера определяет.
Может это какие-то особенности Ubuntu-сервера?

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


From nginx-forum на forum.nginx.org  Thu Jul 23 08:43:11 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Thu, 23 Jul 2020 04:43:11 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LDQstC40LvRjNC90L4g0YHQutC70LXQuNGC0Ywgd3d3?=
 =?UTF-8?B?INC90LAg0LHQtdC3IHd3dz8=?=
In-Reply-To: <811794be-3113-6a10-868f-051f3580445a@ya.ru>
References: <811794be-3113-6a10-868f-051f3580445a@ya.ru>
Message-ID: <9807955e1f178b0141ca8b4722702e0f.NginxMailingListRussian@forum.nginx.org>

В DNS прописаны сервера, то-есть ip по домену определяет.
Может это особенности ubuntu-сервера?

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


From chipitsine на gmail.com  Thu Jul 23 08:53:23 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 23 Jul 2020 13:53:23 +0500
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LDQstC40LvRjNC90L4g0YHQutC70LXQuNGC0Ywgd3d3?=
 =?UTF-8?B?INC90LAg0LHQtdC3IHd3dz8=?=
In-Reply-To: <9807955e1f178b0141ca8b4722702e0f.NginxMailingListRussian@forum.nginx.org>
References: <811794be-3113-6a10-868f-051f3580445a@ya.ru>
 <9807955e1f178b0141ca8b4722702e0f.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQGh_dcJoXdGfjvS-WTZLh5e5wXR-E5bogGDM_xMB980rQ@mail.gmail.com>

попробуйте другой линукс ?

чт, 23 июл. 2020 г. в 13:43, akoval <nginx-forum на forum.nginx.org>:

> В DNS прописаны сервера, то-есть ip по домену определяет.
> Может это особенности ubuntu-сервера?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288770,288812#msg-288812
>
> _______________________________________________
> 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/20200723/af3ed772/attachment.htm>

From nginx-forum на forum.nginx.org  Thu Jul 23 09:04:32 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Thu, 23 Jul 2020 05:04:32 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LDQstC40LvRjNC90L4g0YHQutC70LXQuNGC0Ywgd3d3?=
 =?UTF-8?B?INC90LAg0LHQtdC3IHd3dz8=?=
In-Reply-To: <CAFHpkQGh_dcJoXdGfjvS-WTZLh5e5wXR-E5bogGDM_xMB980rQ@mail.gmail.com>
References: <CAFHpkQGh_dcJoXdGfjvS-WTZLh5e5wXR-E5bogGDM_xMB980rQ@mail.gmail.com>
Message-ID: <48720492aebf0b6db84958e56454fcaa.NginxMailingListRussian@forum.nginx.org>

уже не могу) придеться с этим разбираться

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


From nginx-forum на forum.nginx.org  Thu Jul 23 14:53:38 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Thu, 23 Jul 2020 10:53:38 -0400
Subject: =?UTF-8?B?UmU6INCa0LDQuiDQv9GA0LDQstC40LvRjNC90L4g0YHQutC70LXQuNGC0Ywgd3d3?=
 =?UTF-8?B?INC90LAg0LHQtdC3IHd3dz8=?=
In-Reply-To: <48720492aebf0b6db84958e56454fcaa.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQGh_dcJoXdGfjvS-WTZLh5e5wXR-E5bogGDM_xMB980rQ@mail.gmail.com>
 <48720492aebf0b6db84958e56454fcaa.NginxMailingListRussian@forum.nginx.org>
Message-ID: <929335ec8578329b9fea7c5916fa2d8f.NginxMailingListRussian@forum.nginx.org>

похоже причина в банальном отсутствии А-записи с www (

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


From slw на zxy.spb.ru  Thu Jul 23 15:27:49 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Thu, 23 Jul 2020 18:27:49 +0300
Subject: =?UTF-8?B?bmdpbngg0Lgg0LfQsNCy0YvRiNC10L3QuNC1INGC0YDQsNGE0LjQutCwLg==?=
Message-ID: <20200723152749.GU2015@zxy.spb.ru>

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

В чем может быть дело? Куда копать?

From mdounin на mdounin.ru  Thu Jul 23 15:54:16 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 23 Jul 2020 18:54:16 +0300
Subject: =?UTF-8?B?UmU6IG5naW54INC4INC30LDQstGL0YjQtdC90LjQtSDRgtGA0LDRhNC40LrQsC4=?=
In-Reply-To: <20200723152749.GU2015@zxy.spb.ru>
References: <20200723152749.GU2015@zxy.spb.ru>
Message-ID: <20200723155416.GV12747@mdounin.ru>

Hello!

On Thu, Jul 23, 2020 at 06:27:49PM +0300, Slawa Olhovchenkov wrote:

> В nginx 1.19.1 трафик который он считает отданным клиенту примерно в
> два раза больше того что учитывается сетевым оборудованием.
> 
> В чем может быть дело? Куда копать?

Что значит "трафик который он считает отданным клиенту"?  Речь про 
сумму значений переменных $bytes_sent?  Эта переменная отражает 
количество байт, отправелнных клиенту, то есть записанных в буфер 
сокета.  Что дальше с этими байтами происходило - nginx'у 
незвестно, если клиент их получать на уровне TCP не стал и закрыл 
соединение - то значение $bytes_sent может быть больше, чем ушло 
через интерфейс, на размер буфера сокета.  Дальше уже вопрос к 
типичным размерам ответов, размерам буферов и поведению клиентов.

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

From slw на zxy.spb.ru  Thu Jul 23 16:09:41 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Thu, 23 Jul 2020 19:09:41 +0300
Subject: =?UTF-8?B?UmU6IG5naW54INC4INC30LDQstGL0YjQtdC90LjQtSDRgtGA0LDRhNC40LrQsC4=?=
In-Reply-To: <20200723155416.GV12747@mdounin.ru>
References: <20200723152749.GU2015@zxy.spb.ru>
 <20200723155416.GV12747@mdounin.ru>
Message-ID: <20200723160941.GV2015@zxy.spb.ru>

On Thu, Jul 23, 2020 at 06:54:16PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Thu, Jul 23, 2020 at 06:27:49PM +0300, Slawa Olhovchenkov wrote:
> 
> > В nginx 1.19.1 трафик который он считает отданным клиенту примерно в
> > два раза больше того что учитывается сетевым оборудованием.
> > 
> > В чем может быть дело? Куда копать?
> 
> Что значит "трафик который он считает отданным клиенту"?  Речь про 
> сумму значений переменных $bytes_sent?  Эта переменная отражает 
> количество байт, отправелнных клиенту, то есть записанных в буфер 
> сокета.  Что дальше с этими байтами происходило - nginx'у 
> незвестно, если клиент их получать на уровне TCP не стал и закрыл 
> соединение - то значение $bytes_sent может быть больше, чем ушло 
> через интерфейс, на размер буфера сокета.  Дальше уже вопрос к 
> типичным размерам ответов, размерам буферов и поведению клиентов.

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

From bgx на protva.ru  Thu Jul 23 16:35:35 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Thu, 23 Jul 2020 19:35:35 +0300
Subject: =?UTF-8?B?UmU6IG5naW54INC4INC30LDQstGL0YjQtdC90LjQtSDRgtGA0LDRhNC40LrQsC4=?=
In-Reply-To: <20200723160941.GV2015@zxy.spb.ru>
References: <20200723152749.GU2015@zxy.spb.ru>
 <20200723155416.GV12747@mdounin.ru>
 <20200723160941.GV2015@zxy.spb.ru>
Message-ID: <20200723163535.GL25373@sie.protva.ru>

On Thu, Jul 23, 2020 at 07:09:41PM +0300, Slawa Olhovchenkov wrote:
> это все понятно и очевидно, но два раза -- это два раза.
> типичный размер ответа -- 400кб, клиенты сокет до получения ответа
> закрывать не должны.

 Можно запустить tcpdump и посмотреть, сколько отдаётся клиенту.
 Эта утилита прямо номера байт с начала коннекции покажет.
 В нормальной сети можно ещё накинуть ещё 2-5% на ретрасмиссии.
 Плюс есть счётчики интерфейсов (там будет больше на L2-заголовки,
 что в для mtu=1500 максимум пару процентов добавит). И станет ясно,
 адресовать претензии к nginx или к канальному оборудованию.
-- 
 Eugene Berdnikov

From chipitsine на gmail.com  Thu Jul 23 16:40:22 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 23 Jul 2020 21:40:22 +0500
Subject: =?UTF-8?B?UmU6IG5naW54INC4INC30LDQstGL0YjQtdC90LjQtSDRgtGA0LDRhNC40LrQsC4=?=
In-Reply-To: <20200723163535.GL25373@sie.protva.ru>
References: <20200723152749.GU2015@zxy.spb.ru>
 <20200723155416.GV12747@mdounin.ru>
 <20200723160941.GV2015@zxy.spb.ru> <20200723163535.GL25373@sie.protva.ru>
Message-ID: <CAFHpkQGDKHKS_J3tUOu=qmncVbX0xosSOGg2TZCOA536EJm68g@mail.gmail.com>

а научите, как $bytes_sent  должен биться с SSL ?

чт, 23 июл. 2020 г. в 21:35, Evgeniy Berdnikov <bgx на protva.ru>:

> On Thu, Jul 23, 2020 at 07:09:41PM +0300, Slawa Olhovchenkov wrote:
> > это все понятно и очевидно, но два раза -- это два раза.
> > типичный размер ответа -- 400кб, клиенты сокет до получения ответа
> > закрывать не должны.
>
>  Можно запустить tcpdump и посмотреть, сколько отдаётся клиенту.
>  Эта утилита прямо номера байт с начала коннекции покажет.
>  В нормальной сети можно ещё накинуть ещё 2-5% на ретрасмиссии.
>  Плюс есть счётчики интерфейсов (там будет больше на L2-заголовки,
>  что в для mtu=1500 максимум пару процентов добавит). И станет ясно,
>  адресовать претензии к nginx или к канальному оборудованию.
> --
>  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/20200723/178eb694/attachment.htm>

From slw на zxy.spb.ru  Thu Jul 23 16:54:09 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Thu, 23 Jul 2020 19:54:09 +0300
Subject: =?UTF-8?B?UmU6IG5naW54INC4INC30LDQstGL0YjQtdC90LjQtSDRgtGA0LDRhNC40LrQsC4=?=
In-Reply-To: <20200723163535.GL25373@sie.protva.ru>
References: <20200723152749.GU2015@zxy.spb.ru>
 <20200723155416.GV12747@mdounin.ru>
 <20200723160941.GV2015@zxy.spb.ru>
 <20200723163535.GL25373@sie.protva.ru>
Message-ID: <20200723165409.GW2015@zxy.spb.ru>

On Thu, Jul 23, 2020 at 07:35:35PM +0300, Evgeniy Berdnikov wrote:

> On Thu, Jul 23, 2020 at 07:09:41PM +0300, Slawa Olhovchenkov wrote:
> > это все понятно и очевидно, но два раза -- это два раза.
> > типичный размер ответа -- 400кб, клиенты сокет до получения ответа
> > закрывать не должны.
> 
>  Можно запустить tcpdump и посмотреть, сколько отдаётся клиенту.
>  Эта утилита прямо номера байт с начала коннекции покажет.
>  В нормальной сети можно ещё накинуть ещё 2-5% на ретрасмиссии.
>  Плюс есть счётчики интерфейсов (там будет больше на L2-заголовки,
>  что в для mtu=1500 максимум пару процентов добавит). И станет ясно,
>  адресовать претензии к nginx или к канальному оборудованию.

я не понимаю к чему это все, я уже сказал -- канальное оборудование
(системные счетчики и свитчевые) показывают в два раза МЕНЬШЕ трафика
чем по учету bytes_sent.

PS: а что, ssl как-то хитро bytes_sent искажает?

From chipitsine на gmail.com  Thu Jul 23 16:56:39 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 23 Jul 2020 21:56:39 +0500
Subject: =?UTF-8?B?UmU6IG5naW54INC4INC30LDQstGL0YjQtdC90LjQtSDRgtGA0LDRhNC40LrQsC4=?=
In-Reply-To: <20200723165409.GW2015@zxy.spb.ru>
References: <20200723152749.GU2015@zxy.spb.ru>
 <20200723155416.GV12747@mdounin.ru>
 <20200723160941.GV2015@zxy.spb.ru> <20200723163535.GL25373@sie.protva.ru>
 <20200723165409.GW2015@zxy.spb.ru>
Message-ID: <CAFHpkQH2SFKUasDmi-bNRH8NAHWg+JXjH0YpaFmmdx3Zy3BV5Q@mail.gmail.com>

чт, 23 июл. 2020 г. в 21:54, Slawa Olhovchenkov <slw на zxy.spb.ru>:

> On Thu, Jul 23, 2020 at 07:35:35PM +0300, Evgeniy Berdnikov wrote:
>
> > On Thu, Jul 23, 2020 at 07:09:41PM +0300, Slawa Olhovchenkov wrote:
> > > это все понятно и очевидно, но два раза -- это два раза.
> > > типичный размер ответа -- 400кб, клиенты сокет до получения ответа
> > > закрывать не должны.
> >
> >  Можно запустить tcpdump и посмотреть, сколько отдаётся клиенту.
> >  Эта утилита прямо номера байт с начала коннекции покажет.
> >  В нормальной сети можно ещё накинуть ещё 2-5% на ретрасмиссии.
> >  Плюс есть счётчики интерфейсов (там будет больше на L2-заголовки,
> >  что в для mtu=1500 максимум пару процентов добавит). И станет ясно,
> >  адресовать претензии к nginx или к канальному оборудованию.
>
> я не понимаю к чему это все, я уже сказал -- канальное оборудование
> (системные счетчики и свитчевые) показывают в два раза МЕНЬШЕ трафика
> чем по учету bytes_sent.
>
> PS: а что, ssl как-то хитро bytes_sent искажает?
>

ваш случай выбивается из того, что мы обычно видим.

обычно, за счет SSL добавляется оверхеда (который непонятно как посчитать)



> _______________________________________________
> 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/20200723/606c2af1/attachment-0001.htm>

From mdounin на mdounin.ru  Thu Jul 23 17:22:34 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 23 Jul 2020 20:22:34 +0300
Subject: =?UTF-8?B?UmU6IG5naW54INC4INC30LDQstGL0YjQtdC90LjQtSDRgtGA0LDRhNC40LrQsC4=?=
In-Reply-To: <20200723160941.GV2015@zxy.spb.ru>
References: <20200723152749.GU2015@zxy.spb.ru>
 <20200723155416.GV12747@mdounin.ru>
 <20200723160941.GV2015@zxy.spb.ru>
Message-ID: <20200723172234.GW12747@mdounin.ru>

Hello!

On Thu, Jul 23, 2020 at 07:09:41PM +0300, Slawa Olhovchenkov wrote:

> On Thu, Jul 23, 2020 at 06:54:16PM +0300, Maxim Dounin wrote:
> 
> > Hello!
> > 
> > On Thu, Jul 23, 2020 at 06:27:49PM +0300, Slawa Olhovchenkov wrote:
> > 
> > > В nginx 1.19.1 трафик который он считает отданным клиенту примерно в
> > > два раза больше того что учитывается сетевым оборудованием.
> > > 
> > > В чем может быть дело? Куда копать?
> > 
> > Что значит "трафик который он считает отданным клиенту"?  Речь про 
> > сумму значений переменных $bytes_sent?  Эта переменная отражает 
> > количество байт, отправелнных клиенту, то есть записанных в буфер 
> > сокета.  Что дальше с этими байтами происходило - nginx'у 
> > незвестно, если клиент их получать на уровне TCP не стал и закрыл 
> > соединение - то значение $bytes_sent может быть больше, чем ушло 
> > через интерфейс, на размер буфера сокета.  Дальше уже вопрос к 
> > типичным размерам ответов, размерам буферов и поведению клиентов.
> 
> это все понятно и очевидно, но два раза -- это два раза.
> типичный размер ответа -- 400кб, клиенты сокет до получения ответа
> закрывать не должны.

Ну вот столь же очевидное место практической проверки - 
предположение про "не должны".  Если действительно не закрывают - 
есть повод для разбирательства, а если таки закрывают - то 
наблюдаемый эффект хорошо объясняется поведением клиентов.

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

Впрочем, два раза - возможно, объясняется куда проще: суммарные 
значения $bytes_sent считаются неправильно и каждый запрос 
учитываетстя два раза.  Начиная от банального "запрос пишется в 
лог дважды" и до "запрос дополнительно проксируется локально, и 
считается как ответ клиенту, так и локальный ответ".

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

From bgx на protva.ru  Thu Jul 23 17:33:25 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Thu, 23 Jul 2020 20:33:25 +0300
Subject: =?UTF-8?B?UmU6IG5naW54INC4INC30LDQstGL0YjQtdC90LjQtSDRgtGA0LDRhNC40LrQsC4=?=
In-Reply-To: <20200723165409.GW2015@zxy.spb.ru>
References: <20200723152749.GU2015@zxy.spb.ru>
 <20200723155416.GV12747@mdounin.ru>
 <20200723160941.GV2015@zxy.spb.ru>
 <20200723163535.GL25373@sie.protva.ru>
 <20200723165409.GW2015@zxy.spb.ru>
Message-ID: <20200723173325.GM25373@sie.protva.ru>

On Thu, Jul 23, 2020 at 07:54:09PM +0300, Slawa Olhovchenkov wrote:
> On Thu, Jul 23, 2020 at 07:35:35PM +0300, Evgeniy Berdnikov wrote:
...
> >  что в для mtu=1500 максимум пару процентов добавит). И станет ясно,
> >  адресовать претензии к nginx или к канальному оборудованию.
> 
> я не понимаю к чему это все, я уже сказал -- канальное оборудование
> (системные счетчики и свитчевые) показывают в два раза МЕНЬШЕ трафика
> чем по учету bytes_sent.

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

 Запишите дамп ОДНОЙ коннекции. Если $bytes_sent окажется вдвое меньше
 аппаратных счётчиков, то либо это бага в nginx, либо там 50% заголовков
 и ретрансмиссий, но тогда они в дампе будут отлично видны.
-- 
 Eugene Berdnikov

From slw на zxy.spb.ru  Thu Jul 23 17:39:04 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Thu, 23 Jul 2020 20:39:04 +0300
Subject: =?UTF-8?B?UmU6IG5naW54INC4INC30LDQstGL0YjQtdC90LjQtSDRgtGA0LDRhNC40LrQsC4=?=
In-Reply-To: <20200723173325.GM25373@sie.protva.ru>
References: <20200723152749.GU2015@zxy.spb.ru>
 <20200723155416.GV12747@mdounin.ru>
 <20200723160941.GV2015@zxy.spb.ru>
 <20200723163535.GL25373@sie.protva.ru>
 <20200723165409.GW2015@zxy.spb.ru>
 <20200723173325.GM25373@sie.protva.ru>
Message-ID: <20200723173904.GX2015@zxy.spb.ru>


On Thu, Jul 23, 2020 at 08:33:25PM +0300, Evgeniy Berdnikov wrote:

> On Thu, Jul 23, 2020 at 07:54:09PM +0300, Slawa Olhovchenkov wrote:
> > On Thu, Jul 23, 2020 at 07:35:35PM +0300, Evgeniy Berdnikov wrote:
> ...
> > >  что в для mtu=1500 максимум пару процентов добавит). И станет ясно,
> > >  адресовать претензии к nginx или к канальному оборудованию.
> > 
> > я не понимаю к чему это все, я уже сказал -- канальное оборудование
> > (системные счетчики и свитчевые) показывают в два раза МЕНЬШЕ трафика
> > чем по учету bytes_sent.
> 
>  Чтобы понять, какая из двух линеек крива, следует приложить третью.

Что непонятно в следующем утверждении: счетчики l2 от операционной
системы и свича совпадают? Это канает как две дополнительных линейки?

>  А чтобы не путаться в лесу, лучше всего изучить отдельную сосну.
> 
>  Запишите дамп ОДНОЙ коннекции. Если $bytes_sent окажется вдвое меньше
>  аппаратных счётчиков, то либо это бага в nginx, либо там 50% заголовков
>  и ретрансмиссий, но тогда они в дампе будут отлично видны.

Откуда я для одной конекции возьму аппартные счетчики?

Каким образом 50% заголовков и ретрансмиссий дадут вдвое меньше
трафика на апапртаных счетчиках?

From chipitsine на gmail.com  Thu Jul 23 18:08:43 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 23 Jul 2020 23:08:43 +0500
Subject: =?UTF-8?B?UmU6IG5naW54INC4INC30LDQstGL0YjQtdC90LjQtSDRgtGA0LDRhNC40LrQsC4=?=
In-Reply-To: <20200723173904.GX2015@zxy.spb.ru>
References: <20200723152749.GU2015@zxy.spb.ru>
 <20200723155416.GV12747@mdounin.ru>
 <20200723160941.GV2015@zxy.spb.ru> <20200723163535.GL25373@sie.protva.ru>
 <20200723165409.GW2015@zxy.spb.ru> <20200723173325.GM25373@sie.protva.ru>
 <20200723173904.GX2015@zxy.spb.ru>
Message-ID: <CAFHpkQFUdk6TMdKt7OdK_cy+2OzqwYhvZ1bB_By-yWwzgKJvBQ@mail.gmail.com>

чт, 23 июл. 2020 г. в 22:39, Slawa Olhovchenkov <slw на zxy.spb.ru>:

>
> On Thu, Jul 23, 2020 at 08:33:25PM +0300, Evgeniy Berdnikov wrote:
>
> > On Thu, Jul 23, 2020 at 07:54:09PM +0300, Slawa Olhovchenkov wrote:
> > > On Thu, Jul 23, 2020 at 07:35:35PM +0300, Evgeniy Berdnikov wrote:
> > ...
> > > >  что в для mtu=1500 максимум пару процентов добавит). И станет ясно,
> > > >  адресовать претензии к nginx или к канальному оборудованию.
> > >
> > > я не понимаю к чему это все, я уже сказал -- канальное оборудование
> > > (системные счетчики и свитчевые) показывают в два раза МЕНЬШЕ трафика
> > > чем по учету bytes_sent.
> >
> >  Чтобы понять, какая из двух линеек крива, следует приложить третью.
>
> Что непонятно в следующем утверждении: счетчики l2 от операционной
> системы и свича совпадают? Это канает как две дополнительных линейки?
>
> >  А чтобы не путаться в лесу, лучше всего изучить отдельную сосну.
> >
> >  Запишите дамп ОДНОЙ коннекции. Если $bytes_sent окажется вдвое меньше
> >  аппаратных счётчиков, то либо это бага в nginx, либо там 50% заголовков
> >  и ретрансмиссий, но тогда они в дампе будут отлично видны.
>
> Откуда я для одной конекции возьму аппартные счетчики?
>
> Каким образом 50% заголовков и ретрансмиссий дадут вдвое меньше
> трафика на апапртаных счетчиках?
>

а подзапросы используются ?

конфиг это proxy_pass или что-то хитрее ?


> _______________________________________________
> 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/20200723/fddeaa50/attachment.htm>

From slw на zxy.spb.ru  Thu Jul 23 18:57:53 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Thu, 23 Jul 2020 21:57:53 +0300
Subject: =?UTF-8?B?UmU6IG5naW54INC4INC30LDQstGL0YjQtdC90LjQtSDRgtGA0LDRhNC40LrQsC4=?=
In-Reply-To: <CAFHpkQFUdk6TMdKt7OdK_cy+2OzqwYhvZ1bB_By-yWwzgKJvBQ@mail.gmail.com>
References: <20200723152749.GU2015@zxy.spb.ru>
 <20200723155416.GV12747@mdounin.ru>
 <20200723160941.GV2015@zxy.spb.ru>
 <20200723163535.GL25373@sie.protva.ru>
 <20200723165409.GW2015@zxy.spb.ru>
 <20200723173325.GM25373@sie.protva.ru>
 <20200723173904.GX2015@zxy.spb.ru>
 <CAFHpkQFUdk6TMdKt7OdK_cy+2OzqwYhvZ1bB_By-yWwzgKJvBQ@mail.gmail.com>
Message-ID: <20200723185753.GY2015@zxy.spb.ru>

On Thu, Jul 23, 2020 at 11:08:43PM +0500, Илья Шипицин wrote:

> чт, 23 июл. 2020 г. в 22:39, Slawa Olhovchenkov <slw на zxy.spb.ru>:
> 
> >
> > On Thu, Jul 23, 2020 at 08:33:25PM +0300, Evgeniy Berdnikov wrote:
> >
> > > On Thu, Jul 23, 2020 at 07:54:09PM +0300, Slawa Olhovchenkov wrote:
> > > > On Thu, Jul 23, 2020 at 07:35:35PM +0300, Evgeniy Berdnikov wrote:
> > > ...
> > > > >  что в для mtu=1500 максимум пару процентов добавит). И станет ясно,
> > > > >  адресовать претензии к nginx или к канальному оборудованию.
> > > >
> > > > я не понимаю к чему это все, я уже сказал -- канальное оборудование
> > > > (системные счетчики и свитчевые) показывают в два раза МЕНЬШЕ трафика
> > > > чем по учету bytes_sent.
> > >
> > >  Чтобы понять, какая из двух линеек крива, следует приложить третью.
> >
> > Что непонятно в следующем утверждении: счетчики l2 от операционной
> > системы и свича совпадают? Это канает как две дополнительных линейки?
> >
> > >  А чтобы не путаться в лесу, лучше всего изучить отдельную сосну.
> > >
> > >  Запишите дамп ОДНОЙ коннекции. Если $bytes_sent окажется вдвое меньше
> > >  аппаратных счётчиков, то либо это бага в nginx, либо там 50% заголовков
> > >  и ретрансмиссий, но тогда они в дампе будут отлично видны.
> >
> > Откуда я для одной конекции возьму аппартные счетчики?
> >
> > Каким образом 50% заголовков и ретрансмиссий дадут вдвое меньше
> > трафика на апапртаных счетчиках?
> >
> 
> а подзапросы используются ?

для auth_request

> конфиг это proxy_pass или что-то хитрее ?

auth_request
aws_sign (но он трафика не делает)
proxy_cache

ну и переписывание URI.

что еще может влиять?

From slw на zxy.spb.ru  Fri Jul 24 11:13:57 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Fri, 24 Jul 2020 14:13:57 +0300
Subject: =?UTF-8?B?anNvbiBsb2cg0LggItGN0LrRgNCw0L3QuNGA0L7QstCw0L3QuNC1IiDQvdC10L4=?=
 =?UTF-8?B?0L/RgNC10LTQtdC70LXQvdC90YvRhSDQv9C10YDQtdC80LXQvdC90YvRhQ==?=
Message-ID: <20200724111357.GZ2015@zxy.spb.ru>

Внезапно выяснилось что если пишем в json формате (ну ок,
экранирование json), то отсутсвующе числовые значения все ломают.
они идут как "-". может в этом случае их выводить как null?

From chipitsine на gmail.com  Fri Jul 24 11:17:11 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 24 Jul 2020 16:17:11 +0500
Subject: =?UTF-8?B?UmU6IGpzb24gbG9nINC4ICLRjdC60YDQsNC90LjRgNC+0LLQsNC90LjQtSIg0L0=?=
 =?UTF-8?B?0LXQvtC/0YDQtdC00LXQu9C10L3QvdGL0YUg0L/QtdGA0LXQvNC10L3QvdGL?=
 =?UTF-8?B?0YU=?=
In-Reply-To: <20200724111357.GZ2015@zxy.spb.ru>
References: <20200724111357.GZ2015@zxy.spb.ru>
Message-ID: <CAFHpkQG7xLK5p4oGSRP9KxMuo2Xgz3R8=Q6nQUK7ppxbCHoN1A@mail.gmail.com>

через map можете назначить свою переменную и логировать уже ее.

а что за переменные ? просто, там есть, например, upstream_response_time,
он может быть числом (если ответил один бекенд), прочерком (если не ответил
ни один), и комбинацией чисел и прочерков через запятую (если несколько
бекендов зафейлили, а последний ответил)

пт, 24 июл. 2020 г. в 16:14, Slawa Olhovchenkov <slw на zxy.spb.ru>:

> Внезапно выяснилось что если пишем в json формате (ну ок,
> экранирование json), то отсутсвующе числовые значения все ломают.
> они идут как "-". может в этом случае их выводить как null?
> _______________________________________________
> 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/20200724/f57547d7/attachment-0001.htm>

From slw на zxy.spb.ru  Fri Jul 24 11:20:53 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Fri, 24 Jul 2020 14:20:53 +0300
Subject: =?UTF-8?B?UmU6IGpzb24gbG9nINC4ICLRjdC60YDQsNC90LjRgNC+0LLQsNC90LjQtSIg0L0=?=
 =?UTF-8?B?0LXQvtC/0YDQtdC00LXQu9C10L3QvdGL0YUg0L/QtdGA0LXQvNC10L3QvdGL?=
 =?UTF-8?B?0YU=?=
In-Reply-To: <CAFHpkQG7xLK5p4oGSRP9KxMuo2Xgz3R8=Q6nQUK7ppxbCHoN1A@mail.gmail.com>
References: <20200724111357.GZ2015@zxy.spb.ru>
 <CAFHpkQG7xLK5p4oGSRP9KxMuo2Xgz3R8=Q6nQUK7ppxbCHoN1A@mail.gmail.com>
Message-ID: <20200724112053.GA2015@zxy.spb.ru>

On Fri, Jul 24, 2020 at 04:17:11PM +0500, Илья Шипицин wrote:

> через map можете назначить свою переменную и логировать уже ее.

ну вот для upstream_response_time так прокатит ли?
и не правильней ли все же при экранировании json это делать на уровне mod_log?

> а что за переменные ? просто, там есть, например, upstream_response_time,
> он может быть числом (если ответил один бекенд), прочерком (если не ответил
> ни один), и комбинацией чисел и прочерков через запятую (если несколько
> бекендов зафейлили, а последний ответил)

вообще да, именно он.

> пт, 24 июл. 2020 г. в 16:14, Slawa Olhovchenkov <slw на zxy.spb.ru>:
> 
> > Внезапно выяснилось что если пишем в json формате (ну ок,
> > экранирование json), то отсутсвующе числовые значения все ломают.
> > они идут как "-". может в этом случае их выводить как null?
> > _______________________________________________
> > 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


From slw на zxy.spb.ru  Fri Jul 24 11:54:16 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Fri, 24 Jul 2020 14:54:16 +0300
Subject: =?UTF-8?B?UmU6IG5naW54INC4INC30LDQstGL0YjQtdC90LjQtSDRgtGA0LDRhNC40LrQsC4=?=
In-Reply-To: <20200723172234.GW12747@mdounin.ru>
References: <20200723152749.GU2015@zxy.spb.ru>
 <20200723155416.GV12747@mdounin.ru>
 <20200723160941.GV2015@zxy.spb.ru>
 <20200723172234.GW12747@mdounin.ru>
Message-ID: <20200724115416.GB2015@zxy.spb.ru>

On Thu, Jul 23, 2020 at 08:22:34PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Thu, Jul 23, 2020 at 07:09:41PM +0300, Slawa Olhovchenkov wrote:
> 
> > On Thu, Jul 23, 2020 at 06:54:16PM +0300, Maxim Dounin wrote:
> > 
> > > Hello!
> > > 
> > > On Thu, Jul 23, 2020 at 06:27:49PM +0300, Slawa Olhovchenkov wrote:
> > > 
> > > > В nginx 1.19.1 трафик который он считает отданным клиенту примерно в
> > > > два раза больше того что учитывается сетевым оборудованием.
> > > > 
> > > > В чем может быть дело? Куда копать?
> > > 
> > > Что значит "трафик который он считает отданным клиенту"?  Речь про 
> > > сумму значений переменных $bytes_sent?  Эта переменная отражает 
> > > количество байт, отправелнных клиенту, то есть записанных в буфер 
> > > сокета.  Что дальше с этими байтами происходило - nginx'у 
> > > незвестно, если клиент их получать на уровне TCP не стал и закрыл 
> > > соединение - то значение $bytes_sent может быть больше, чем ушло 
> > > через интерфейс, на размер буфера сокета.  Дальше уже вопрос к 
> > > типичным размерам ответов, размерам буферов и поведению клиентов.
> > 
> > это все понятно и очевидно, но два раза -- это два раза.
> > типичный размер ответа -- 400кб, клиенты сокет до получения ответа
> > закрывать не должны.
> 
> Ну вот столь же очевидное место практической проверки - 
> предположение про "не должны".  Если действительно не закрывают - 
> есть повод для разбирательства, а если таки закрывают - то 
> наблюдаемый эффект хорошо объясняется поведением клиентов.
> 
> При таких размерах ответ скорее всего целиком влезает в буфер 
> сокета, и два раза - это примерно каждый второй ответ остался 
> неотправленным.  Должно быть хорошо видно, если сличать глазами 
> логи и пакеты к соответствующим клиентам из дампа траффика.

Всё-таки это клиенты.
Они закрывают сокет иной раз после отправки им 50кб ответа (из 256кб
буфера).

From chipitsine на gmail.com  Fri Jul 24 12:04:52 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 24 Jul 2020 17:04:52 +0500
Subject: =?UTF-8?B?UmU6IGpzb24gbG9nINC4ICLRjdC60YDQsNC90LjRgNC+0LLQsNC90LjQtSIg0L0=?=
 =?UTF-8?B?0LXQvtC/0YDQtdC00LXQu9C10L3QvdGL0YUg0L/QtdGA0LXQvNC10L3QvdGL?=
 =?UTF-8?B?0YU=?=
In-Reply-To: <20200724112053.GA2015@zxy.spb.ru>
References: <20200724111357.GZ2015@zxy.spb.ru>
 <CAFHpkQG7xLK5p4oGSRP9KxMuo2Xgz3R8=Q6nQUK7ppxbCHoN1A@mail.gmail.com>
 <20200724112053.GA2015@zxy.spb.ru>
Message-ID: <CAFHpkQFcVbFAbAp9_Gr5Dk7OQQhxH44fNE4FLCxuvOaRwSocbQ@mail.gmail.com>

пт, 24 июл. 2020 г. в 16:20, Slawa Olhovchenkov <slw на zxy.spb.ru>:

> On Fri, Jul 24, 2020 at 04:17:11PM +0500, Илья Шипицин wrote:
>
> > через map можете назначить свою переменную и логировать уже ее.
>
> ну вот для upstream_response_time так прокатит ли?
>

прокатит


> и не правильней ли все же при экранировании json это делать на уровне
> mod_log?
>

у этой переменной список возможных значений

float
-
-, float, float

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


>
> > а что за переменные ? просто, там есть, например, upstream_response_time,
> > он может быть числом (если ответил один бекенд), прочерком (если не
> ответил
> > ни один), и комбинацией чисел и прочерков через запятую (если несколько
> > бекендов зафейлили, а последний ответил)
>
> вообще да, именно он.
>
> > пт, 24 июл. 2020 г. в 16:14, Slawa Olhovchenkov <slw на zxy.spb.ru>:
> >
> > > Внезапно выяснилось что если пишем в json формате (ну ок,
> > > экранирование json), то отсутсвующе числовые значения все ломают.
> > > они идут как "-". может в этом случае их выводить как null?
> > > _______________________________________________
> > > nginx-ru mailing list
> > > nginx-ru на nginx.org
> > > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru на nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200724/93cc2631/attachment.htm>

From panzercheg на gmail.com  Sun Jul 26 09:11:20 2020
From: panzercheg на gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQkdGD0YDQtdC90LrQvtCy?=)
Date: Sun, 26 Jul 2020 12:11:20 +0300
Subject: =?UTF-8?B?0JLQvtC30LzQvtC20L3QviDQu9C4INC+0YHRgtCw0L3QvtCy0LjRgtGMINCy0Ys=?=
 =?UTF-8?B?0L/QvtC70L3QtdC90LjQtSDQv9GA0LDQstC40Lsg0LLQvdGD0YLRgNC4IGxv?=
 =?UTF-8?B?Y2F0aW9uL9Cy0YvQudGC0Lgg0LjQtyBsb2NhdGlvbg==?=
Message-ID: <CAPdBx_WchdAB0apV-c7-STD0uk-ehR0pAi+G7q6XqgEYMxWNQg@mail.gmail.com>

Я использую gitlab 12 СE ( 12.9.2 (ac5568eb5d8) ) и nginx из поставки
gitlab (nginx 1.16.1 sha256:f11c2a6d )

кусок моего location с правилами:

location /test/lfs_lock_test.git/info/lfs/locks{
 if ( $args ~ "lockservice=true" ) {
  return 404;
  }
 rewrite ^/test/lfs_lock_test.git/(.*) /$1 break;
 proxy_pass https://localhost:5002;
 access_log  /var/log/gitlab/nginx/lfs_lock_access.log gitlab_access;
 error_log   /var/log/gitlab/nginx/lfs_lock_error.log debug;
}

я хочу обрабатывать все запросы на  ^.*.git/info/lfs/locks внутри location,
только если там не содержится lockservice=true в URI, в это случае,
просто выйти из location ( без 404 ) ,т.к. в файле, который я правлю
( /var/opt/gitlab/nginx/conf/gitlab-http.conf ) есть в т.ч. и такое:

  location / {
    proxy_cache off;
    proxy_pass  http://gitlab-workhorse;
  }

т.е. если есть  lockservice=true в URI, то не делать proxy_pass и в
принципе не применять правила из моего location
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200726/31064a9a/attachment.htm>

From shadow.tehb на gmail.com  Sun Jul 26 09:28:43 2020
From: shadow.tehb на gmail.com (=?UTF-8?B?0KHQtdGA0LPQtdC5INCe0LvQtdCz0L7QstC40Yc=?=)
Date: Sun, 26 Jul 2020 12:28:43 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LvQuCDQvtGB0YLQsNC90L7QstC40YLRjCA=?=
 =?UTF-8?B?0LLRi9C/0L7Qu9C90LXQvdC40LUg0L/RgNCw0LLQuNC7INCy0L3Rg9GC0YA=?=
 =?UTF-8?B?0LggbG9jYXRpb24v0LLRi9C50YLQuCDQuNC3IGxvY2F0aW9u?=
In-Reply-To: <CAPdBx_WchdAB0apV-c7-STD0uk-ehR0pAi+G7q6XqgEYMxWNQg@mail.gmail.com>
References: <CAPdBx_WchdAB0apV-c7-STD0uk-ehR0pAi+G7q6XqgEYMxWNQg@mail.gmail.com>
Message-ID: <1738a73f8f8.2797.c9c0c8e23854510de0246f8a19aa7b8d@gmail.com>

Можно в if засунуть rewrite ... last; Тогда после выполнения условия будет 
совершён выход из этого location и поиск нового в соответствии с 
изменениями. Но мне сходу видятся проблемы, т.к. изначально логика 
построена неверно.

Роман Буренков <panzercheg на gmail.com> 26 июля 2020 г. 12:11:41 написал:
> Я использую gitlab 12 СE ( 12.9.2 (ac5568eb5d8) ) и nginx из поставки 
> gitlab (nginx 1.16.1 sha256:f11c2a6d )
>
> кусок моего location с правилами:
> location /test/lfs_lock_test.git/info/lfs/locks{ if ( $args ~ 
> "lockservice=true" ) { return 404; } rewrite ^/test/lfs_lock_test.git/(.*) 
> /$1 break; proxy_pass https://localhost:5002; access_log 
> /var/log/gitlab/nginx/lfs_lock_access.log gitlab_access; error_log 
> /var/log/gitlab/nginx/lfs_lock_error.log debug;
> }
> я хочу обрабатывать все запросы на ^.*.git/info/lfs/locks внутри location,
> только если там не содержится lockservice=true в URI, в это случае,
> просто выйти из location ( без 404 ) ,т.к. в файле, который я правлю
> ( /var/opt/gitlab/nginx/conf/gitlab-http.conf ) есть в т.ч. и такое:
> location / { proxy_cache off; proxy_pass http://gitlab-workhorse; }
> т.е. если есть lockservice=true в URI, то не делать proxy_pass и в принципе 
> не применять правила из моего location
>
> _______________________________________________
> 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/20200726/ce8919f1/attachment.htm>

From pluknet на nginx.com  Sun Jul 26 14:55:57 2020
From: pluknet на nginx.com (Sergey Kandaurov)
Date: Sun, 26 Jul 2020 17:55:57 +0300
Subject: =?UTF-8?B?UmU6IGpzb24gbG9nINC4ICLRjdC60YDQsNC90LjRgNC+0LLQsNC90LjQtSIg0L0=?=
 =?UTF-8?B?0LXQvtC/0YDQtdC00LXQu9C10L3QvdGL0YUg0L/QtdGA0LXQvNC10L3QvdGL?=
 =?UTF-8?B?0YU=?=
In-Reply-To: <20200724111357.GZ2015@zxy.spb.ru>
References: <20200724111357.GZ2015@zxy.spb.ru>
Message-ID: <3A0889CA-CD47-4E0A-B51C-8D9F297F918B@nginx.com>


> On 24 Jul 2020, at 14:13, Slawa Olhovchenkov <slw на zxy.spb.ru> wrote:
> 
> Внезапно выяснилось что если пишем в json формате (ну ок,
> экранирование json), то отсутсвующе числовые значения все ломают.
> они идут как "-". может в этом случае их выводить как null?

Такая подстановка используется в эскейпинге по умолчанию,
если значение переменной не найдено.  В других форматах
эскейпинга значение не выводится, подробнее здесь:
http://nginx.org/r/log_format/ru

-- 
Sergey Kandaurov


From slw на zxy.spb.ru  Sun Jul 26 16:15:20 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Sun, 26 Jul 2020 19:15:20 +0300
Subject: =?UTF-8?B?UmU6IGpzb24gbG9nINC4ICLRjdC60YDQsNC90LjRgNC+0LLQsNC90LjQtSIg0L0=?=
 =?UTF-8?B?0LXQvtC/0YDQtdC00LXQu9C10L3QvdGL0YUg0L/QtdGA0LXQvNC10L3QvdGL?=
 =?UTF-8?B?0YU=?=
In-Reply-To: <3A0889CA-CD47-4E0A-B51C-8D9F297F918B@nginx.com>
References: <20200724111357.GZ2015@zxy.spb.ru>
 <3A0889CA-CD47-4E0A-B51C-8D9F297F918B@nginx.com>
Message-ID: <20200726161520.GC2015@zxy.spb.ru>

On Sun, Jul 26, 2020 at 05:55:57PM +0300, Sergey Kandaurov wrote:

> 
> > On 24 Jul 2020, at 14:13, Slawa Olhovchenkov <slw на zxy.spb.ru> wrote:
> > 
> > Внезапно выяснилось что если пишем в json формате (ну ок,
> > экранирование json), то отсутсвующе числовые значения все ломают.
> > они идут как "-". может в этом случае их выводить как null?
> 
> Такая подстановка используется в эскейпинге по умолчанию,
> если значение переменной не найдено.  В других форматах
> эскейпинга значение не выводится, подробнее здесь:
> http://nginx.org/r/log_format/ru

ну по спецификации json отстувиие должно кодироваться как null, не?

From vbart на nginx.com  Sun Jul 26 16:29:04 2020
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Sun, 26 Jul 2020 19:29:04 +0300
Subject: =?UTF-8?B?UmU6IGpzb24gbG9nINC4ICLRjdC60YDQsNC90LjRgNC+0LLQsNC90LjQtSIg0L0=?=
 =?UTF-8?B?0LXQvtC/0YDQtdC00LXQu9C10L3QvdGL0YUg0L/QtdGA0LXQvNC10L3QvdGL?=
 =?UTF-8?B?0YU=?=
In-Reply-To: <20200726161520.GC2015@zxy.spb.ru>
References: <20200724111357.GZ2015@zxy.spb.ru>
 <3A0889CA-CD47-4E0A-B51C-8D9F297F918B@nginx.com>
 <20200726161520.GC2015@zxy.spb.ru>
Message-ID: <2032572.irdbgypaU6@vbart-laptop>

On Sunday, 26 July 2020 19:15:20 MSK Slawa Olhovchenkov wrote:
> On Sun, Jul 26, 2020 at 05:55:57PM +0300, Sergey Kandaurov wrote:
> 
> > 
> > > On 24 Jul 2020, at 14:13, Slawa Olhovchenkov <slw на zxy.spb.ru> wrote:
> > > 
> > > Внезапно выяснилось что если пишем в json формате (ну ок,
> > > экранирование json), то отсутсвующе числовые значения все ломают.
> > > они идут как "-". может в этом случае их выводить как null?
> > 
> > Такая подстановка используется в эскейпинге по умолчанию,
> > если значение переменной не найдено.  В других форматах
> > эскейпинга значение не выводится, подробнее здесь:
> > http://nginx.org/r/log_format/ru
> 
> ну по спецификации json отстувиие должно кодироваться как null, не?

Это где такое написано? 

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

From slw на zxy.spb.ru  Sun Jul 26 16:42:58 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Sun, 26 Jul 2020 19:42:58 +0300
Subject: =?UTF-8?B?UmU6IGpzb24gbG9nINC4ICLRjdC60YDQsNC90LjRgNC+0LLQsNC90LjQtSIg0L0=?=
 =?UTF-8?B?0LXQvtC/0YDQtdC00LXQu9C10L3QvdGL0YUg0L/QtdGA0LXQvNC10L3QvdGL?=
 =?UTF-8?B?0YU=?=
In-Reply-To: <2032572.irdbgypaU6@vbart-laptop>
References: <20200724111357.GZ2015@zxy.spb.ru>
 <3A0889CA-CD47-4E0A-B51C-8D9F297F918B@nginx.com>
 <20200726161520.GC2015@zxy.spb.ru>
 <2032572.irdbgypaU6@vbart-laptop>
Message-ID: <20200726164258.GD2015@zxy.spb.ru>

On Sun, Jul 26, 2020 at 07:29:04PM +0300, Валентин Бартенев wrote:

> On Sunday, 26 July 2020 19:15:20 MSK Slawa Olhovchenkov wrote:
> > On Sun, Jul 26, 2020 at 05:55:57PM +0300, Sergey Kandaurov wrote:
> > 
> > > 
> > > > On 24 Jul 2020, at 14:13, Slawa Olhovchenkov <slw на zxy.spb.ru> wrote:
> > > > 
> > > > Внезапно выяснилось что если пишем в json формате (ну ок,
> > > > экранирование json), то отсутсвующе числовые значения все ломают.
> > > > они идут как "-". может в этом случае их выводить как null?
> > > 
> > > Такая подстановка используется в эскейпинге по умолчанию,
> > > если значение переменной не найдено.  В других форматах
> > > эскейпинга значение не выводится, подробнее здесь:
> > > http://nginx.org/r/log_format/ru
> > 
> > ну по спецификации json отстувиие должно кодироваться как null, не?
> 
> Это где такое написано? 

https://stackoverflow.com/questions/21120999/representing-null-in-json

в предположении что значение числовое.

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

From chipitsine на gmail.com  Sun Jul 26 16:52:35 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sun, 26 Jul 2020 21:52:35 +0500
Subject: =?UTF-8?B?UmU6IGpzb24gbG9nINC4ICLRjdC60YDQsNC90LjRgNC+0LLQsNC90LjQtSIg0L0=?=
 =?UTF-8?B?0LXQvtC/0YDQtdC00LXQu9C10L3QvdGL0YUg0L/QtdGA0LXQvNC10L3QvdGL?=
 =?UTF-8?B?0YU=?=
In-Reply-To: <20200726164258.GD2015@zxy.spb.ru>
References: <20200724111357.GZ2015@zxy.spb.ru>
 <3A0889CA-CD47-4E0A-B51C-8D9F297F918B@nginx.com>
 <20200726161520.GC2015@zxy.spb.ru> <2032572.irdbgypaU6@vbart-laptop>
 <20200726164258.GD2015@zxy.spb.ru>
Message-ID: <CAFHpkQEpgECW2UXYT1ocF9O6q==2VjFJ+iSYBE_qH4qAXhX8sA@mail.gmail.com>

вс, 26 июл. 2020 г. в 21:43, Slawa Olhovchenkov <slw на zxy.spb.ru>:

> On Sun, Jul 26, 2020 at 07:29:04PM +0300, Валентин Бартенев wrote:
>
> > On Sunday, 26 July 2020 19:15:20 MSK Slawa Olhovchenkov wrote:
> > > On Sun, Jul 26, 2020 at 05:55:57PM +0300, Sergey Kandaurov wrote:
> > >
> > > >
> > > > > On 24 Jul 2020, at 14:13, Slawa Olhovchenkov <slw на zxy.spb.ru>
> wrote:
> > > > >
> > > > > Внезапно выяснилось что если пишем в json формате (ну ок,
> > > > > экранирование json), то отсутсвующе числовые значения все ломают.
> > > > > они идут как "-". может в этом случае их выводить как null?
> > > >
> > > > Такая подстановка используется в эскейпинге по умолчанию,
> > > > если значение переменной не найдено.  В других форматах
> > > > эскейпинга значение не выводится, подробнее здесь:
> > > > http://nginx.org/r/log_format/ru
> > >
> > > ну по спецификации json отстувиие должно кодироваться как null, не?
> >
> > Это где такое написано?
>
> https://stackoverflow.com/questions/21120999/representing-null-in-json
>
> в предположении что значение числовое.
>

а как правильно ескейпить "0.001, - , 0.002"


>
> в любом случае варианта выводить ничего нет -- для чисел будет не
> валидный json, а все числа пихать в виде строк в "" -- как-то тоже
> кажется неправильным.
> _______________________________________________
> 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/20200726/c0f39e62/attachment.htm>

From slw на zxy.spb.ru  Sun Jul 26 17:05:30 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Sun, 26 Jul 2020 20:05:30 +0300
Subject: =?UTF-8?B?UmU6IGpzb24gbG9nINC4ICLRjdC60YDQsNC90LjRgNC+0LLQsNC90LjQtSIg0L0=?=
 =?UTF-8?B?0LXQvtC/0YDQtdC00LXQu9C10L3QvdGL0YUg0L/QtdGA0LXQvNC10L3QvdGL?=
 =?UTF-8?B?0YU=?=
In-Reply-To: <CAFHpkQEpgECW2UXYT1ocF9O6q==2VjFJ+iSYBE_qH4qAXhX8sA@mail.gmail.com>
References: <20200724111357.GZ2015@zxy.spb.ru>
 <3A0889CA-CD47-4E0A-B51C-8D9F297F918B@nginx.com>
 <20200726161520.GC2015@zxy.spb.ru>
 <2032572.irdbgypaU6@vbart-laptop>
 <20200726164258.GD2015@zxy.spb.ru>
 <CAFHpkQEpgECW2UXYT1ocF9O6q==2VjFJ+iSYBE_qH4qAXhX8sA@mail.gmail.com>
Message-ID: <20200726170530.GE2015@zxy.spb.ru>

On Sun, Jul 26, 2020 at 09:52:35PM +0500, Илья Шипицин wrote:

> > https://stackoverflow.com/questions/21120999/representing-null-in-json
> >
> > в предположении что значение числовое.
> >
> 
> а как правильно ескейпить "0.001, - , 0.002"

да, хороший вопрос
только почему у нас два ответа?

но я думаю что если одно число -- то как число
если ничего -- не было обращений к апстирму -- null
иначе строка в кавычках.

From chipitsine на gmail.com  Sun Jul 26 17:07:23 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sun, 26 Jul 2020 22:07:23 +0500
Subject: =?UTF-8?B?UmU6IGpzb24gbG9nINC4ICLRjdC60YDQsNC90LjRgNC+0LLQsNC90LjQtSIg0L0=?=
 =?UTF-8?B?0LXQvtC/0YDQtdC00LXQu9C10L3QvdGL0YUg0L/QtdGA0LXQvNC10L3QvdGL?=
 =?UTF-8?B?0YU=?=
In-Reply-To: <20200726170530.GE2015@zxy.spb.ru>
References: <20200724111357.GZ2015@zxy.spb.ru>
 <3A0889CA-CD47-4E0A-B51C-8D9F297F918B@nginx.com>
 <20200726161520.GC2015@zxy.spb.ru> <2032572.irdbgypaU6@vbart-laptop>
 <20200726164258.GD2015@zxy.spb.ru>
 <CAFHpkQEpgECW2UXYT1ocF9O6q==2VjFJ+iSYBE_qH4qAXhX8sA@mail.gmail.com>
 <20200726170530.GE2015@zxy.spb.ru>
Message-ID: <CAFHpkQF6KJ6ZAniGGQDYKrw-xTa5ZfR9QzvayoeLOc-4ttqK5g@mail.gmail.com>

вс, 26 июл. 2020 г. в 22:05, Slawa Olhovchenkov <slw на zxy.spb.ru>:

> On Sun, Jul 26, 2020 at 09:52:35PM +0500, Илья Шипицин wrote:
>
> > > https://stackoverflow.com/questions/21120999/representing-null-in-json
> > >
> > > в предположении что значение числовое.
> > >
> >
> > а как правильно ескейпить "0.001, - , 0.002"
>

первый бекенд вернул 503
второй сбросил tcp
третий вернул 200

и у меня proxy_next_upstream http_503


>
> да, хороший вопрос
> только почему у нас два ответа?
>
> но я думаю что если одно число -- то как число
> если ничего -- не было обращений к апстирму -- null
> иначе строка в кавычках.
> _______________________________________________
> 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/20200726/c5eb5c22/attachment-0001.htm>

From slw на zxy.spb.ru  Sun Jul 26 17:10:38 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Sun, 26 Jul 2020 20:10:38 +0300
Subject: =?UTF-8?B?UmU6IGpzb24gbG9nINC4ICLRjdC60YDQsNC90LjRgNC+0LLQsNC90LjQtSIg0L0=?=
 =?UTF-8?B?0LXQvtC/0YDQtdC00LXQu9C10L3QvdGL0YUg0L/QtdGA0LXQvNC10L3QvdGL?=
 =?UTF-8?B?0YU=?=
In-Reply-To: <CAFHpkQF6KJ6ZAniGGQDYKrw-xTa5ZfR9QzvayoeLOc-4ttqK5g@mail.gmail.com>
References: <20200724111357.GZ2015@zxy.spb.ru>
 <3A0889CA-CD47-4E0A-B51C-8D9F297F918B@nginx.com>
 <20200726161520.GC2015@zxy.spb.ru>
 <2032572.irdbgypaU6@vbart-laptop>
 <20200726164258.GD2015@zxy.spb.ru>
 <CAFHpkQEpgECW2UXYT1ocF9O6q==2VjFJ+iSYBE_qH4qAXhX8sA@mail.gmail.com>
 <20200726170530.GE2015@zxy.spb.ru>
 <CAFHpkQF6KJ6ZAniGGQDYKrw-xTa5ZfR9QzvayoeLOc-4ttqK5g@mail.gmail.com>
Message-ID: <20200726171038.GF2015@zxy.spb.ru>

On Sun, Jul 26, 2020 at 10:07:23PM +0500, Илья Шипицин wrote:

> вс, 26 июл. 2020 г. в 22:05, Slawa Olhovchenkov <slw на zxy.spb.ru>:
> 
> > On Sun, Jul 26, 2020 at 09:52:35PM +0500, Илья Шипицин wrote:
> >
> > > > https://stackoverflow.com/questions/21120999/representing-null-in-json
> > > >
> > > > в предположении что значение числовое.
> > > >
> > >
> > > а как правильно ескейпить "0.001, - , 0.002"
> >
> 
> первый бекенд вернул 503
> второй сбросил tcp
> третий вернул 200

а, ок.
ну в общем я вариант сказал.

а может даже так [0.001,null,0.002]

> и у меня proxy_next_upstream http_503
> 
> 
> >
> > да, хороший вопрос
> > только почему у нас два ответа?
> >
> > но я думаю что если одно число -- то как число
> > если ничего -- не было обращений к апстирму -- null
> > иначе строка в кавычках.
> > _______________________________________________
> > 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


From slw на zxy.spb.ru  Sun Jul 26 17:47:40 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Sun, 26 Jul 2020 20:47:40 +0300
Subject: tcpdump tls
Message-ID: <20200726174740.GG2015@zxy.spb.ru>

А что-как можно сделать что бы расшифровать https сессию в .pcap?

Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет,
типа

====
Server's response

Full response:
    0 Missing status code HTTP/1.1
=====


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

From onokonem на gmail.com  Sun Jul 26 17:58:00 2020
From: onokonem на gmail.com (Daniel Podolsky)
Date: Sun, 26 Jul 2020 20:58:00 +0300
Subject: tcpdump tls
In-Reply-To: <20200726174740.GG2015@zxy.spb.ru>
References: <20200726174740.GG2015@zxy.spb.ru>
Message-ID: <CAKaHDOHnZhvqWvPsga3VU389jia9Bbi4PM0ARWFQmeprtFg0rA@mail.gmail.com>

только на спецом сконфигурированных ciphers. но, вообще-то, это гуглится.

On Sun, 26 Jul 2020 at 20:47, Slawa Olhovchenkov <slw на zxy.spb.ru> wrote:
>
> А что-как можно сделать что бы расшифровать https сессию в .pcap?
>
> Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет,
> типа
>
> ====
> Server's response
>
> Full response:
>     0 Missing status code HTTP/1.1
> =====
>
>
> и я хочу своими глазами увидеть что конкретно ему отправилось и что
> именно пришло.
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From slw на zxy.spb.ru  Sun Jul 26 18:00:08 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Sun, 26 Jul 2020 21:00:08 +0300
Subject: tcpdump tls
In-Reply-To: <CAKaHDOHnZhvqWvPsga3VU389jia9Bbi4PM0ARWFQmeprtFg0rA@mail.gmail.com>
References: <20200726174740.GG2015@zxy.spb.ru>
 <CAKaHDOHnZhvqWvPsga3VU389jia9Bbi4PM0ARWFQmeprtFg0rA@mail.gmail.com>
Message-ID: <20200726180008.GH2015@zxy.spb.ru>

On Sun, Jul 26, 2020 at 08:58:00PM +0300, Daniel Podolsky wrote:

> только на спецом сконфигурированных ciphers. но, вообще-то, это гуглится.

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

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

From chipitsine на gmail.com  Sun Jul 26 18:02:23 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sun, 26 Jul 2020 23:02:23 +0500
Subject: tcpdump tls
In-Reply-To: <20200726174740.GG2015@zxy.spb.ru>
References: <20200726174740.GG2015@zxy.spb.ru>
Message-ID: <CAFHpkQEgNnHx8yUiy=_3TS8n0Mgoe0D_g5qtQdUvjgvhLC5YDw@mail.gmail.com>

Возможно проще fiddler на стороне браузера

On Sun, Jul 26, 2020, 10:47 PM Slawa Olhovchenkov <slw на zxy.spb.ru> wrote:

> А что-как можно сделать что бы расшифровать https сессию в .pcap?
>
> Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет,
> типа
>
> ====
> Server's response
>
> Full response:
>     0 Missing status code HTTP/1.1
> =====
>
>
> и я хочу своими глазами увидеть что конкретно ему отправилось и что
> именно пришло.
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200726/37c21074/attachment.htm>

From chipitsine на gmail.com  Sun Jul 26 18:04:23 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Sun, 26 Jul 2020 23:04:23 +0500
Subject: tcpdump tls
In-Reply-To: <20200726174740.GG2015@zxy.spb.ru>
References: <20200726174740.GG2015@zxy.spb.ru>
Message-ID: <CAFHpkQHZxHGwj_nWryrMfo0ow7eyX31S49A=n+o5n7D5fzz5Ag@mail.gmail.com>

Если хочется именно pcap, посмотрите, тут на форуме был вопрос про слив
ключей шифрования в ФСБ. Можно подгрузить библиотеку, которая сохранит
ключи в файл

On Sun, Jul 26, 2020, 10:47 PM Slawa Olhovchenkov <slw на zxy.spb.ru> wrote:

> А что-как можно сделать что бы расшифровать https сессию в .pcap?
>
> Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет,
> типа
>
> ====
> Server's response
>
> Full response:
>     0 Missing status code HTTP/1.1
> =====
>
>
> и я хочу своими глазами увидеть что конкретно ему отправилось и что
> именно пришло.
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200726/6856fa8a/attachment.htm>

From vbart на nginx.com  Mon Jul 27 00:37:34 2020
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Mon, 27 Jul 2020 03:37:34 +0300
Subject: =?UTF-8?B?UmU6IGpzb24gbG9nINC4ICLRjdC60YDQsNC90LjRgNC+0LLQsNC90LjQtSIg0L0=?=
 =?UTF-8?B?0LXQvtC/0YDQtdC00LXQu9C10L3QvdGL0YUg0L/QtdGA0LXQvNC10L3QvdGL?=
 =?UTF-8?B?0YU=?=
In-Reply-To: <20200726164258.GD2015@zxy.spb.ru>
References: <20200724111357.GZ2015@zxy.spb.ru>
 <2032572.irdbgypaU6@vbart-laptop> <20200726164258.GD2015@zxy.spb.ru>
Message-ID: <3315706.iIbC2pHGDl@vbart-laptop>

On Sunday, 26 July 2020 19:42:58 MSK Slawa Olhovchenkov wrote:
> On Sun, Jul 26, 2020 at 07:29:04PM +0300, Валентин Бартенев wrote:
> 
> > On Sunday, 26 July 2020 19:15:20 MSK Slawa Olhovchenkov wrote:
> > > On Sun, Jul 26, 2020 at 05:55:57PM +0300, Sergey Kandaurov wrote:
> > > 
> > > > 
> > > > > On 24 Jul 2020, at 14:13, Slawa Olhovchenkov <slw на zxy.spb.ru> wrote:
> > > > > 
> > > > > Внезапно выяснилось что если пишем в json формате (ну ок,
> > > > > экранирование json), то отсутсвующе числовые значения все ломают.
> > > > > они идут как "-". может в этом случае их выводить как null?
> > > > 
> > > > Такая подстановка используется в эскейпинге по умолчанию,
> > > > если значение переменной не найдено.  В других форматах
> > > > эскейпинга значение не выводится, подробнее здесь:
> > > > http://nginx.org/r/log_format/ru
> > > 
> > > ну по спецификации json отстувиие должно кодироваться как null, не?
> > 
> > Это где такое написано? 
> 
> https://stackoverflow.com/questions/21120999/representing-null-in-json
> 

Это не спецификация, а предпочтения пользователей StackOverflow.


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


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

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

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

From panzercheg на gmail.com  Mon Jul 27 06:16:29 2020
From: panzercheg на gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQkdGD0YDQtdC90LrQvtCy?=)
Date: Mon, 27 Jul 2020 09:16:29 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LvQuCDQvtGB0YLQsNC90L7QstC40YLRjCA=?=
 =?UTF-8?B?0LLRi9C/0L7Qu9C90LXQvdC40LUg0L/RgNCw0LLQuNC7INCy0L3Rg9GC0YA=?=
 =?UTF-8?B?0LggbG9jYXRpb24v0LLRi9C50YLQuCDQuNC3IGxvY2F0aW9u?=
In-Reply-To: <mailman.0.1595764800.66663.nginx-ru@nginx.org>
References: <mailman.0.1595764800.66663.nginx-ru@nginx.org>
Message-ID: <CAPdBx_XGA73+gZNCwOTjG-uspNtjC30xk=2o8ch7GNVb9Q7XbQ@mail.gmail.com>

А какая была бы более правильная логика? Я изначально хотел сделать 2
правила с (?)(?!) но почему в таком regex`е у меня всё равно не тот url,
что я хотел просачивался в location (  location ~
(?^/.*.git/info/lfs/locks$)(?!^.*&lockservice=true$))

вс, 26 июл. 2020 г. в 15:00, <nginx-ru-request на nginx.org>:

> Сообщения, предназначенные для списка
> рассылки nginx-ru, отправляйте по адресу
>         nginx-ru на nginx.org
>
> Для изменения параметров подписки или
> отписки используйте веб-страницу
>         http://mailman.nginx.org/mailman/listinfo/nginx-ru
> или отправьте письмо, в теле или теме
> которого будет слово 'help', по адресу
>         nginx-ru-request на nginx.org
>
> Адрес администратора этого списка
> рассылки:
>         nginx-ru-owner на nginx.org
>
> При ответе, пожалуйста, измените тему
> письма на более содержательную чем "Re:
> Содержание дайджеста списка рассылки
> nginx-ru..."
> В этом номере:
>
>    1. Возможно ли остановить
>       выполнение правил внутри
>       location/выйти из location (Роман Буренков)
>    2. Re: Возможно ли остановить
>       выполнение правил внутри
>       location/выйти из location (Сергей Олегович)
>
>
>
> ---------- Forwarded message ----------
> From: "Роман Буренков" <panzercheg на gmail.com>
> To: nginx-ru на nginx.org
> Cc:
> Bcc:
> Date: Sun, 26 Jul 2020 12:11:20 +0300
> Subject: Возможно ли остановить выполнение правил внутри location/выйти из
> location
> Я использую gitlab 12 СE ( 12.9.2 (ac5568eb5d8) ) и nginx из поставки
> gitlab (nginx 1.16.1 sha256:f11c2a6d )
>
> кусок моего location с правилами:
>
> location /test/lfs_lock_test.git/info/lfs/locks{
>  if ( $args ~ "lockservice=true" ) {
>   return 404;
>   }
>  rewrite ^/test/lfs_lock_test.git/(.*) /$1 break;
>  proxy_pass https://localhost:5002;
>  access_log  /var/log/gitlab/nginx/lfs_lock_access.log gitlab_access;
>  error_log   /var/log/gitlab/nginx/lfs_lock_error.log debug;
> }
>
> я хочу обрабатывать все запросы на  ^.*.git/info/lfs/locks внутри location,
> только если там не содержится lockservice=true в URI, в это случае,
> просто выйти из location ( без 404 ) ,т.к. в файле, который я правлю
> ( /var/opt/gitlab/nginx/conf/gitlab-http.conf ) есть в т.ч. и такое:
>
>   location / {
>     proxy_cache off;
>     proxy_pass  http://gitlab-workhorse;
>   }
>
> т.е. если есть  lockservice=true в URI, то не делать proxy_pass и в принципе не применять правила из моего location
>
>
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: "Сергей Олегович" <shadow.tehb на gmail.com>
> To: <nginx-ru на nginx.org>
> Cc:
> Bcc:
> Date: Sun, 26 Jul 2020 12:28:43 +0300
> Subject: Re: Возможно ли остановить выполнение правил внутри
> location/выйти из location
> Можно в if засунуть rewrite ... last; Тогда после выполнения условия будет
> совершён выход из этого location и поиск нового в соответствии с
> изменениями. Но мне сходу видятся проблемы, т.к. изначально логика
> построена неверно.
>
> Роман Буренков <panzercheg на gmail.com> 26 июля 2020 г. 12:11:41 написал:
>
>> Я использую gitlab 12 СE ( 12.9.2 (ac5568eb5d8) ) и nginx из поставки
>> gitlab (nginx 1.16.1 sha256:f11c2a6d )
>>
>> кусок моего location с правилами:
>>
>> location /test/lfs_lock_test.git/info/lfs/locks{
>>  if ( $args ~ "lockservice=true" ) {
>>   return 404;
>>   }
>>  rewrite ^/test/lfs_lock_test.git/(.*) /$1 break;
>>  proxy_pass https://localhost:5002;
>>  access_log  /var/log/gitlab/nginx/lfs_lock_access.log gitlab_access;
>>  error_log   /var/log/gitlab/nginx/lfs_lock_error.log debug;
>> }
>>
>> я хочу обрабатывать все запросы на  ^.*.git/info/lfs/locks внутри location,
>> только если там не содержится lockservice=true в URI, в это случае,
>> просто выйти из location ( без 404 ) ,т.к. в файле, который я правлю
>> ( /var/opt/gitlab/nginx/conf/gitlab-http.conf ) есть в т.ч. и такое:
>>
>>   location / {
>>     proxy_cache off;
>>     proxy_pass  http://gitlab-workhorse;
>>   }
>>
>> т.е. если есть  lockservice=true в URI, то не делать proxy_pass и в принципе не применять правила из моего location
>>
>>
>>
>>
>>
>>
>>  _______________________________________________
>> 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/20200727/04026737/attachment-0001.htm>

From kulmaks на gmail.com  Mon Jul 27 06:54:02 2020
From: kulmaks на gmail.com (Maksim Kulik)
Date: Mon, 27 Jul 2020 09:54:02 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LvQuCDQvtGB0YLQsNC90L7QstC40YLRjCA=?=
 =?UTF-8?B?0LLRi9C/0L7Qu9C90LXQvdC40LUg0L/RgNCw0LLQuNC7INCy0L3Rg9GC0YA=?=
 =?UTF-8?B?0LggbG9jYXRpb24v0LLRi9C50YLQuCDQuNC3IGxvY2F0aW9u?=
In-Reply-To: <CAPdBx_XGA73+gZNCwOTjG-uspNtjC30xk=2o8ch7GNVb9Q7XbQ@mail.gmail.com>
References: <mailman.0.1595764800.66663.nginx-ru@nginx.org>
 <CAPdBx_XGA73+gZNCwOTjG-uspNtjC30xk=2o8ch7GNVb9Q7XbQ@mail.gmail.com>
Message-ID: <CA+zavHn=xtG8SwiSroNb4sEe-hika49tU9QkUePez4sTbXEovw@mail.gmail.com>

Можно после if делать внутренний редирект на другой локейшен (если,
конечно, в вашем случае нет какой-то сложной дальнейшей обработки и вас
интересует только то, что записано в location / ) при помощи error_page. То
есть:

error_page 420 = @special_location;

location /test/lfs_lock_test.git/info/lfs/locks{
 if ( $args ~ "lockservice=true" ) {
  return 420;
  }
 rewrite ^/test/lfs_lock_test.git/(.*) /$1 break;
 proxy_pass https://localhost:5002;
 access_log  /var/log/gitlab/nginx/lfs_lock_access.log gitlab_access;
 error_log   /var/log/gitlab/nginx/lfs_lock_error.log debug;
}

location @special_location {
    proxy_cache off;
    proxy_pass  http://gitlab-workhorse;
}

пн, 27 июл. 2020 г. в 09:16, Роман Буренков <panzercheg на gmail.com>:

>
> А какая была бы более правильная логика? Я изначально хотел сделать 2
> правила с (?)(?!) но почему в таком regex`е у меня всё равно не тот url,
> что я хотел просачивался в location (  location ~
> (?^/.*.git/info/lfs/locks$)(?!^.*&lockservice=true$))
>
> вс, 26 июл. 2020 г. в 15:00, <nginx-ru-request на nginx.org>:
>
>> Сообщения, предназначенные для списка
>> рассылки nginx-ru, отправляйте по адресу
>>         nginx-ru на nginx.org
>>
>> Для изменения параметров подписки или
>> отписки используйте веб-страницу
>>         http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> или отправьте письмо, в теле или теме
>> которого будет слово 'help', по адресу
>>         nginx-ru-request на nginx.org
>>
>> Адрес администратора этого списка
>> рассылки:
>>         nginx-ru-owner на nginx.org
>>
>> При ответе, пожалуйста, измените тему
>> письма на более содержательную чем "Re:
>> Содержание дайджеста списка рассылки
>> nginx-ru..."
>> В этом номере:
>>
>>    1. Возможно ли остановить
>>       выполнение правил внутри
>>       location/выйти из location (Роман Буренков)
>>    2. Re: Возможно ли остановить
>>       выполнение правил внутри
>>       location/выйти из location (Сергей Олегович)
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: "Роман Буренков" <panzercheg на gmail.com>
>> To: nginx-ru на nginx.org
>> Cc:
>> Bcc:
>> Date: Sun, 26 Jul 2020 12:11:20 +0300
>> Subject: Возможно ли остановить выполнение правил внутри location/выйти
>> из location
>> Я использую gitlab 12 СE ( 12.9.2 (ac5568eb5d8) ) и nginx из поставки
>> gitlab (nginx 1.16.1 sha256:f11c2a6d )
>>
>> кусок моего location с правилами:
>>
>> location /test/lfs_lock_test.git/info/lfs/locks{
>>  if ( $args ~ "lockservice=true" ) {
>>   return 404;
>>   }
>>  rewrite ^/test/lfs_lock_test.git/(.*) /$1 break;
>>  proxy_pass https://localhost:5002;
>>  access_log  /var/log/gitlab/nginx/lfs_lock_access.log gitlab_access;
>>  error_log   /var/log/gitlab/nginx/lfs_lock_error.log debug;
>> }
>>
>> я хочу обрабатывать все запросы на  ^.*.git/info/lfs/locks внутри location,
>> только если там не содержится lockservice=true в URI, в это случае,
>> просто выйти из location ( без 404 ) ,т.к. в файле, который я правлю
>> ( /var/opt/gitlab/nginx/conf/gitlab-http.conf ) есть в т.ч. и такое:
>>
>>   location / {
>>     proxy_cache off;
>>     proxy_pass  http://gitlab-workhorse;
>>   }
>>
>> т.е. если есть  lockservice=true в URI, то не делать proxy_pass и в принципе не применять правила из моего location
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: "Сергей Олегович" <shadow.tehb на gmail.com>
>> To: <nginx-ru на nginx.org>
>> Cc:
>> Bcc:
>> Date: Sun, 26 Jul 2020 12:28:43 +0300
>> Subject: Re: Возможно ли остановить выполнение правил внутри
>> location/выйти из location
>> Можно в if засунуть rewrite ... last; Тогда после выполнения условия
>> будет совершён выход из этого location и поиск нового в соответствии с
>> изменениями. Но мне сходу видятся проблемы, т.к. изначально логика
>> построена неверно.
>>
>> Роман Буренков <panzercheg на gmail.com> 26 июля 2020 г. 12:11:41 написал:
>>
>>> Я использую gitlab 12 СE ( 12.9.2 (ac5568eb5d8) ) и nginx из поставки
>>> gitlab (nginx 1.16.1 sha256:f11c2a6d )
>>>
>>> кусок моего location с правилами:
>>>
>>> location /test/lfs_lock_test.git/info/lfs/locks{
>>>  if ( $args ~ "lockservice=true" ) {
>>>   return 404;
>>>   }
>>>  rewrite ^/test/lfs_lock_test.git/(.*) /$1 break;
>>>  proxy_pass https://localhost:5002;
>>>  access_log  /var/log/gitlab/nginx/lfs_lock_access.log gitlab_access;
>>>  error_log   /var/log/gitlab/nginx/lfs_lock_error.log debug;
>>> }
>>>
>>> я хочу обрабатывать все запросы на  ^.*.git/info/lfs/locks внутри location,
>>> только если там не содержится lockservice=true в URI, в это случае,
>>> просто выйти из location ( без 404 ) ,т.к. в файле, который я правлю
>>> ( /var/opt/gitlab/nginx/conf/gitlab-http.conf ) есть в т.ч. и такое:
>>>
>>>   location / {
>>>     proxy_cache off;
>>>     proxy_pass  http://gitlab-workhorse;
>>>   }
>>>
>>> т.е. если есть  lockservice=true в URI, то не делать proxy_pass и в принципе не применять правила из моего location
>>>
>>>
>>>
>>>
>>>
>>>
>>>  _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru на nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200727/ddd838aa/attachment-0001.htm>

From bgx на protva.ru  Mon Jul 27 06:56:16 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Mon, 27 Jul 2020 09:56:16 +0300
Subject: tcpdump tls
In-Reply-To: <20200726174740.GG2015@zxy.spb.ru>
References: <20200726174740.GG2015@zxy.spb.ru>
Message-ID: <20200727065616.GY25373@sie.protva.ru>

On Sun, Jul 26, 2020 at 08:47:40PM +0300, Slawa Olhovchenkov wrote:
> А что-как можно сделать что бы расшифровать https сессию в .pcap?

 Это 7 вёрст крюк, проще включить на сервере debug log...

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

-- 
 Eugene Berdnikov

From eugen на grosbein.net  Mon Jul 27 07:43:44 2020
From: eugen на grosbein.net (Eugene Grosbein)
Date: Mon, 27 Jul 2020 14:43:44 +0700
Subject: tcpdump tls
In-Reply-To: <20200726174740.GG2015@zxy.spb.ru>
References: <20200726174740.GG2015@zxy.spb.ru>
Message-ID: <3992f29e-94a3-fc62-e0ea-68f7b89ca6fa@grosbein.net>

27.07.2020 0:47, Slawa Olhovchenkov пишет:

> А что-как можно сделать что бы расшифровать https сессию в .pcap?
> 
> Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет,
> типа
> 
> ====
> Server's response
> 
> Full response:
>     0 Missing status code HTTP/1.1
> =====
> 
> 
> и я хочу своими глазами увидеть что конкретно ему отправилось и что
> именно пришло.

В случае сеансовых ключей RSA можно попробовать в Wireshark:
меню Редактирование/Параметры (Edit/Preference),
дальше Protocols/TLS и там есть место вставить серверный ключ.

Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры
дампить сессионные ключи, чтобы потом можно было их использовать в Wireshark,
в (Pre)-Master-Secret log filename.




From chipitsine на gmail.com  Mon Jul 27 08:28:36 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 27 Jul 2020 13:28:36 +0500
Subject: tcpdump tls
In-Reply-To: <3992f29e-94a3-fc62-e0ea-68f7b89ca6fa@grosbein.net>
References: <20200726174740.GG2015@zxy.spb.ru>
 <3992f29e-94a3-fc62-e0ea-68f7b89ca6fa@grosbein.net>
Message-ID: <CAFHpkQFYszaP_46ti_EnKHiFjb0PPQu4=Dc4R+JyoZFeuHg_LA@mail.gmail.com>

пн, 27 июл. 2020 г. в 12:44, Eugene Grosbein <eugen на grosbein.net>:

> 27.07.2020 0:47, Slawa Olhovchenkov пишет:
>
> > А что-как можно сделать что бы расшифровать https сессию в .pcap?
> >
> > Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет,
> > типа
> >
> > ====
> > Server's response
> >
> > Full response:
> >     0 Missing status code HTTP/1.1
> > =====
> >
> >
> > и я хочу своими глазами увидеть что конкретно ему отправилось и что
> > именно пришло.
>
> В случае сеансовых ключей RSA можно попробовать в Wireshark:
> меню Редактирование/Параметры (Edit/Preference),
> дальше Protocols/TLS и там есть место вставить серверный ключ.
>


тут, вероятно, стоит сделать оговорку про FPS (forward perfect secrecy).
давным-давно, когда зрители фильмов про чебурашку еще были детьми, шифры
были такие,
что имея закрытый ключ сервера можно было декодировать SSL сессию.

потом пришли безопасники, сказали "непорядок" и ввели FPS шифры (сейчас
почти все такие, если вы специально
не ограничите, и то, не факт, что современный браузер будет с таким
работать).


поэтому нужны сессионные ключи. которые можно стырить из браузера или из
nginx (через специальную библиотеку)


>
> Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры
> дампить сессионные ключи, чтобы потом можно было их использовать в
> Wireshark,
> в (Pre)-Master-Secret log filename.
>
>
>
> _______________________________________________
> 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/20200727/c217daf2/attachment.htm>

From slw на zxy.spb.ru  Mon Jul 27 09:13:27 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Mon, 27 Jul 2020 12:13:27 +0300
Subject: tcpdump tls
In-Reply-To: <20200727065616.GY25373@sie.protva.ru>
References: <20200726174740.GG2015@zxy.spb.ru>
 <20200727065616.GY25373@sie.protva.ru>
Message-ID: <20200727091327.GI2015@zxy.spb.ru>

On Mon, Jul 27, 2020 at 09:56:16AM +0300, Evgeniy Berdnikov wrote:

> On Sun, Jul 26, 2020 at 08:47:40PM +0300, Slawa Olhovchenkov wrote:
> > А что-как можно сделать что бы расшифровать https сессию в .pcap?
> 
>  Это 7 вёрст крюк, проще включить на сервере debug log...

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

From slw на zxy.spb.ru  Mon Jul 27 09:15:44 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Mon, 27 Jul 2020 12:15:44 +0300
Subject: tcpdump tls
In-Reply-To: <3992f29e-94a3-fc62-e0ea-68f7b89ca6fa@grosbein.net>
References: <20200726174740.GG2015@zxy.spb.ru>
 <3992f29e-94a3-fc62-e0ea-68f7b89ca6fa@grosbein.net>
Message-ID: <20200727091544.GJ2015@zxy.spb.ru>

On Mon, Jul 27, 2020 at 02:43:44PM +0700, Eugene Grosbein wrote:

> 27.07.2020 0:47, Slawa Olhovchenkov пишет:
> 
> > А что-как можно сделать что бы расшифровать https сессию в .pcap?
> > 
> > Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет,
> > типа
> > 
> > ====
> > Server's response
> > 
> > Full response:
> >     0 Missing status code HTTP/1.1
> > =====
> > 
> > 
> > и я хочу своими глазами увидеть что конкретно ему отправилось и что
> > именно пришло.
> 
> В случае сеансовых ключей RSA можно попробовать в Wireshark:
> меню Редактирование/Параметры (Edit/Preference),
> дальше Protocols/TLS и там есть место вставить серверный ключ.

И брать его из браузера? Как?

> Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры
> дампить сессионные ключи, чтобы потом можно было их использовать в Wireshark,
> в (Pre)-Master-Secret log filename.

Отлично, меня это устроит, какие ключевые слова гуглить?

From eugen на grosbein.net  Mon Jul 27 09:32:20 2020
From: eugen на grosbein.net (Eugene Grosbein)
Date: Mon, 27 Jul 2020 16:32:20 +0700
Subject: tcpdump tls
In-Reply-To: <20200727091544.GJ2015@zxy.spb.ru>
References: <20200726174740.GG2015@zxy.spb.ru>
 <3992f29e-94a3-fc62-e0ea-68f7b89ca6fa@grosbein.net>
 <20200727091544.GJ2015@zxy.spb.ru>
Message-ID: <f021e072-62fa-8097-aa01-f95c32a147dd@grosbein.net>

27.07.2020 16:15, Slawa Olhovchenkov пишет:
> On Mon, Jul 27, 2020 at 02:43:44PM +0700, Eugene Grosbein wrote:

>> В случае сеансовых ключей RSA можно попробовать в Wireshark:
>> меню Редактирование/Параметры (Edit/Preference),
>> дальше Protocols/TLS и там есть место вставить серверный ключ.
> 
> И брать его из браузера? Как?

Тут имелся в виду фиксированный серверный приватный ключ.

>> Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры
>> дампить сессионные ключи, чтобы потом можно было их использовать в Wireshark,
>> в (Pre)-Master-Secret log filename.
> 
> Отлично, меня это устроит, какие ключевые слова гуглить?

Я гуглил так: wireshark decode https
Второй ссылкой было https://support.citrix.com/article/CTX116557
How to Decrypt SSL and TLS Traffic Using Wireshark

Четвертой https://wiki.wireshark.org/TLS#TLS_Decryption


From chipitsine на gmail.com  Mon Jul 27 09:44:37 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 27 Jul 2020 14:44:37 +0500
Subject: tcpdump tls
In-Reply-To: <20200727091544.GJ2015@zxy.spb.ru>
References: <20200726174740.GG2015@zxy.spb.ru>
 <3992f29e-94a3-fc62-e0ea-68f7b89ca6fa@grosbein.net>
 <20200727091544.GJ2015@zxy.spb.ru>
Message-ID: <CAFHpkQG75GR+_4o+kPBpbYPE4DGFrVbA11Trxe9cfGVStfoj6g@mail.gmail.com>

у chrome есть net-internals

https://support.google.com/chrome/a/answer/6271171?hl=en

пн, 27 июл. 2020 г. в 14:15, Slawa Olhovchenkov <slw на zxy.spb.ru>:

> On Mon, Jul 27, 2020 at 02:43:44PM +0700, Eugene Grosbein wrote:
>
> > 27.07.2020 0:47, Slawa Olhovchenkov пишет:
> >
> > > А что-как можно сделать что бы расшифровать https сессию в .pcap?
> > >
> > > Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет,
> > > типа
> > >
> > > ====
> > > Server's response
> > >
> > > Full response:
> > >     0 Missing status code HTTP/1.1
> > > =====
> > >
> > >
> > > и я хочу своими глазами увидеть что конкретно ему отправилось и что
> > > именно пришло.
> >
> > В случае сеансовых ключей RSA можно попробовать в Wireshark:
> > меню Редактирование/Параметры (Edit/Preference),
> > дальше Protocols/TLS и там есть место вставить серверный ключ.
>
> И брать его из браузера? Как?
>
> > Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры
> > дампить сессионные ключи, чтобы потом можно было их использовать в
> Wireshark,
> > в (Pre)-Master-Secret log filename.
>
> Отлично, меня это устроит, какие ключевые слова гуглить?
> _______________________________________________
> 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/20200727/b7b8d9a1/attachment-0001.htm>

From slw на zxy.spb.ru  Mon Jul 27 09:54:36 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Mon, 27 Jul 2020 12:54:36 +0300
Subject: tcpdump tls
In-Reply-To: <f021e072-62fa-8097-aa01-f95c32a147dd@grosbein.net>
References: <20200726174740.GG2015@zxy.spb.ru>
 <3992f29e-94a3-fc62-e0ea-68f7b89ca6fa@grosbein.net>
 <20200727091544.GJ2015@zxy.spb.ru>
 <f021e072-62fa-8097-aa01-f95c32a147dd@grosbein.net>
Message-ID: <20200727095436.GK2015@zxy.spb.ru>

On Mon, Jul 27, 2020 at 04:32:20PM +0700, Eugene Grosbein wrote:

> 27.07.2020 16:15, Slawa Olhovchenkov пишет:
> > On Mon, Jul 27, 2020 at 02:43:44PM +0700, Eugene Grosbein wrote:
> 
> >> В случае сеансовых ключей RSA можно попробовать в Wireshark:
> >> меню Редактирование/Параметры (Edit/Preference),
> >> дальше Protocols/TLS и там есть место вставить серверный ключ.
> > 
> > И брать его из браузера? Как?
> 
> Тут имелся в виду фиксированный серверный приватный ключ.
> 
> >> Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры
> >> дампить сессионные ключи, чтобы потом можно было их использовать в Wireshark,
> >> в (Pre)-Master-Secret log filename.
> > 
> > Отлично, меня это устроит, какие ключевые слова гуглить?
> 
> Я гуглил так: wireshark decode https
> Второй ссылкой было https://support.citrix.com/article/CTX116557
> How to Decrypt SSL and TLS Traffic Using Wireshark
> 
> Четвертой https://wiki.wireshark.org/TLS#TLS_Decryption

Key logging is enabled by setting the environment variable
SSLKEYLOGFILE to point to a file. Note: starting with NSS 3.24 (used
by Firefox 48 and 49 only), the SSLKEYLOGFILE approach is disabled by
default for optimized builds using the Makefile (those using gyp via
build.sh are not affected). Distributors can re-enable it at compile
time though (using the NSS_ALLOW_SSLKEYLOGFILE=1 make variable) which
is done for the official Firefox binaries. (See bug 1188657.) Notably,
Debian does not have this option enabled, see Debian bug 842292.

и народ на SO жалуется что хромы не пишут. даже с  --ssl-key-log-file.

The SSLKEYLOGFILE was originally disabled when the Mozilla team were
debugging an NSS issue in Firefox 65. I had reported the bug here
originally. It was subsequently reenabled in Firefox 66. However, once
again for Firefox 67 it had accidentally been disabled in release
builds again. I once again reopened that original bugzilla ticket to
report it. And they then opened up a new bugzilla task that you linked
in your post. A recent commit has removed the conditional that should
now prevent that bug from reoccurring in future releases. My guess,
the SSLKEYLOGFILE env. variable will work again when Firefox 68
releases, and on some Nightly version very shortly.

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

From slw на zxy.spb.ru  Mon Jul 27 09:59:59 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Mon, 27 Jul 2020 12:59:59 +0300
Subject: tcpdump tls
In-Reply-To: <CAFHpkQG75GR+_4o+kPBpbYPE4DGFrVbA11Trxe9cfGVStfoj6g@mail.gmail.com>
References: <20200726174740.GG2015@zxy.spb.ru>
 <3992f29e-94a3-fc62-e0ea-68f7b89ca6fa@grosbein.net>
 <20200727091544.GJ2015@zxy.spb.ru>
 <CAFHpkQG75GR+_4o+kPBpbYPE4DGFrVbA11Trxe9cfGVStfoj6g@mail.gmail.com>
Message-ID: <20200727095959.GL2015@zxy.spb.ru>

On Mon, Jul 27, 2020 at 02:44:37PM +0500, Илья Шипицин wrote:

> у chrome есть net-internals
> 
> https://support.google.com/chrome/a/answer/6271171?hl=en

интересная штука, но похоже SSL там в нерасшифрованном виде и вопрос
ключей остается.

> пн, 27 июл. 2020 г. в 14:15, Slawa Olhovchenkov <slw на zxy.spb.ru>:
> 
> > On Mon, Jul 27, 2020 at 02:43:44PM +0700, Eugene Grosbein wrote:
> >
> > > 27.07.2020 0:47, Slawa Olhovchenkov пишет:
> > >
> > > > А что-как можно сделать что бы расшифровать https сессию в .pcap?
> > > >
> > > > Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет,
> > > > типа
> > > >
> > > > ====
> > > > Server's response
> > > >
> > > > Full response:
> > > >     0 Missing status code HTTP/1.1
> > > > =====
> > > >
> > > >
> > > > и я хочу своими глазами увидеть что конкретно ему отправилось и что
> > > > именно пришло.
> > >
> > > В случае сеансовых ключей RSA можно попробовать в Wireshark:
> > > меню Редактирование/Параметры (Edit/Preference),
> > > дальше Protocols/TLS и там есть место вставить серверный ключ.
> >
> > И брать его из браузера? Как?
> >
> > > Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры
> > > дампить сессионные ключи, чтобы потом можно было их использовать в
> > Wireshark,
> > > в (Pre)-Master-Secret log filename.
> >
> > Отлично, меня это устроит, какие ключевые слова гуглить?
> > _______________________________________________
> > 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


From panzercheg на gmail.com  Mon Jul 27 10:45:03 2020
From: panzercheg на gmail.com (=?UTF-8?B?0KDQvtC80LDQvSDQkdGD0YDQtdC90LrQvtCy?=)
Date: Mon, 27 Jul 2020 13:45:03 +0300
Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LvQuCDQvtGB0YLQsNC90L7QstC40YLRjCA=?=
 =?UTF-8?B?0LLRi9C/0L7Qu9C90LXQvdC40LUg0L/RgNCw0LLQuNC7INCy0L3Rg9GC0YA=?=
 =?UTF-8?B?0LggbG9jYXRpb24v0LLRi9C50YLQuCDQuNC3IGxvY2F0aW9u?=
In-Reply-To: <mailman.4542.1595832862.2914.nginx-ru@nginx.org>
References: <mailman.4542.1595832862.2914.nginx-ru@nginx.org>
Message-ID: <CAPdBx_V4jRvV=i6kZ=T8dRPBTn9Y_4xD1YYGJF=NnZRKwKwtAQ@mail.gmail.com>

Максим, спасибо огромное! В итоге это именно то, что я и хотел получить.

>
>
> ---------- Forwarded message ----------
> From: Maksim Kulik <kulmaks на gmail.com>
> To: nginx-ru на nginx.org
> Cc:
> Bcc:
> Date: Mon, 27 Jul 2020 09:54:02 +0300
> Subject: Re: Возможно ли остановить выполнение правил внутри
> location/выйти из location
> Можно после if делать внутренний редирект на другой локейшен (если,
> конечно, в вашем случае нет какой-то сложной дальнейшей обработки и вас
> интересует только то, что записано в location / ) при помощи error_page. То
> есть:
>
> error_page 420 = @special_location;
>
> location /test/lfs_lock_test.git/info/lfs/locks{
>  if ( $args ~ "lockservice=true" ) {
>   return 420;
>   }
>  rewrite ^/test/lfs_lock_test.git/(.*) /$1 break;
>  proxy_pass https://localhost:5002;
>  access_log  /var/log/gitlab/nginx/lfs_lock_access.log gitlab_access;
>  error_log   /var/log/gitlab/nginx/lfs_lock_error.log debug;
> }
>
> location @special_location {
>     proxy_cache off;
>     proxy_pass  http://gitlab-workhorse;
> }
>
> пн, 27 июл. 2020 г. в 09:16, Роман Буренков <panzercheg на gmail.com>:
>
>>
>> А какая была бы более правильная логика? Я изначально хотел сделать 2
>> правила с (?)(?!) но почему в таком regex`е у меня всё равно не тот url,
>> что я хотел просачивался в location (  location ~
>> (?^/.*.git/info/lfs/locks$)(?!^.*&lockservice=true$))
>>
>>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200727/8c1e8557/attachment.htm>

From onokonem на gmail.com  Mon Jul 27 11:08:35 2020
From: onokonem на gmail.com (Daniel Podolsky)
Date: Mon, 27 Jul 2020 14:08:35 +0300
Subject: tcpdump tls
In-Reply-To: <20200727095959.GL2015@zxy.spb.ru>
References: <20200726174740.GG2015@zxy.spb.ru>
 <3992f29e-94a3-fc62-e0ea-68f7b89ca6fa@grosbein.net>
 <20200727091544.GJ2015@zxy.spb.ru>
 <CAFHpkQG75GR+_4o+kPBpbYPE4DGFrVbA11Trxe9cfGVStfoj6g@mail.gmail.com>
 <20200727095959.GL2015@zxy.spb.ru>
Message-ID: <CAKaHDOHWG0MwYajYvBeHLyjC_ysqUffmAzFWob0NEE3L1oAEZg@mail.gmail.com>

я, кажется, вот на эту статью ориентировался:
https://www.joji.me/en-us/blog/walkthrough-decrypt-ssl-tls-traffic-https-and-http2-in-wireshark/

On Mon, 27 Jul 2020 at 13:00, Slawa Olhovchenkov <slw на zxy.spb.ru> wrote:
>
> On Mon, Jul 27, 2020 at 02:44:37PM +0500, Илья Шипицин wrote:
>
> > у chrome есть net-internals
> >
> > https://support.google.com/chrome/a/answer/6271171?hl=en
>
> интересная штука, но похоже SSL там в нерасшифрованном виде и вопрос
> ключей остается.
>
> > пн, 27 июл. 2020 г. в 14:15, Slawa Olhovchenkov <slw на zxy.spb.ru>:
> >
> > > On Mon, Jul 27, 2020 at 02:43:44PM +0700, Eugene Grosbein wrote:
> > >
> > > > 27.07.2020 0:47, Slawa Olhovchenkov пишет:
> > > >
> > > > > А что-как можно сделать что бы расшифровать https сессию в .pcap?
> > > > >
> > > > > Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет,
> > > > > типа
> > > > >
> > > > > ====
> > > > > Server's response
> > > > >
> > > > > Full response:
> > > > >     0 Missing status code HTTP/1.1
> > > > > =====
> > > > >
> > > > >
> > > > > и я хочу своими глазами увидеть что конкретно ему отправилось и что
> > > > > именно пришло.
> > > >
> > > > В случае сеансовых ключей RSA можно попробовать в Wireshark:
> > > > меню Редактирование/Параметры (Edit/Preference),
> > > > дальше Protocols/TLS и там есть место вставить серверный ключ.
> > >
> > > И брать его из браузера? Как?
> > >
> > > > Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры
> > > > дампить сессионные ключи, чтобы потом можно было их использовать в
> > > Wireshark,
> > > > в (Pre)-Master-Secret log filename.
> > >
> > > Отлично, меня это устроит, какие ключевые слова гуглить?
> > > _______________________________________________
> > > nginx-ru mailing list
> > > nginx-ru на nginx.org
> > > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru на nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From nginx-forum на forum.nginx.org  Wed Jul 29 06:05:51 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Wed, 29 Jul 2020 02:05:51 -0400
Subject: =?UTF-8?B?QXBhY2hlIFJlZGlyZWN0IDMwMS4g0J/QtdGA0LXQvdCw0L/RgNCw0LLQu9GP0LU=?=
 =?UTF-8?B?0YIg0L3QsCDQvdC10L/RgNCw0LLQuNC70YzQvdGL0Lkg0LvQuNC90Lo=?=
Message-ID: <6901f721f031f6fc65c9f2c083f3c280.NginxMailingListRussian@forum.nginx.org>

Не могу понять в чем сбой...

В htaccess есть список редиректов:
...
Redirect 301 /ua/catalog/likarski-travy/
https://apteka-ds.com.ua/catalog/fitochayi - работает норм
...
Redirect 301 /ua/catalog/vitaminy-grupy-v/neyrovitan-astellas-30-sht/
https://apteka-ds.com.ua/catalog/vitaminy-hrupy-v
этот почему-то редиректит на
https://apteka-ds.com.ua/catalog/vitaminyneyrovitan-astellas-30-sht
...

Что не так? Какие-то запрещенные символы, которые Redirect не может
прочитать? Как это исправить?

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


From nginx-forum на forum.nginx.org  Wed Jul 29 06:13:45 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Wed, 29 Jul 2020 02:13:45 -0400
Subject: =?UTF-8?B?UmU6IEFwYWNoZSBSZWRpcmVjdCAzMDEuINCf0LXRgNC10L3QsNC/0YDQsNCy0Ls=?=
 =?UTF-8?B?0Y/QtdGCINC90LAg0L3QtdC/0YDQsNCy0LjQu9GM0L3Ri9C5INC70LjQvdC6?=
In-Reply-To: <6901f721f031f6fc65c9f2c083f3c280.NginxMailingListRussian@forum.nginx.org>
References: <6901f721f031f6fc65c9f2c083f3c280.NginxMailingListRussian@forum.nginx.org>
Message-ID: <bcfde26e869a9d48c9481e344b484317.NginxMailingListRussian@forum.nginx.org>

При этом такой редирект рабоает:
Redirect 301
/ua/catalog/likarnyanyy-asortyment/slavna-maska-medychna-trysharova-sterylna-na-rezynkakh-slavna-10-sht/
https://apteka-ds.com.ua/catalog/masky-zakhysni-medychni

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


From nginx-forum на forum.nginx.org  Wed Jul 29 06:48:00 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Wed, 29 Jul 2020 02:48:00 -0400
Subject: =?UTF-8?B?UmU6IEFwYWNoZSBSZWRpcmVjdCAzMDEuINCf0LXRgNC10L3QsNC/0YDQsNCy0Ls=?=
 =?UTF-8?B?0Y/QtdGCINC90LAg0L3QtdC/0YDQsNCy0LjQu9GM0L3Ri9C5INC70LjQvdC6?=
In-Reply-To: <bcfde26e869a9d48c9481e344b484317.NginxMailingListRussian@forum.nginx.org>
References: <6901f721f031f6fc65c9f2c083f3c280.NginxMailingListRussian@forum.nginx.org>
 <bcfde26e869a9d48c9481e344b484317.NginxMailingListRussian@forum.nginx.org>
Message-ID: <043499a965f9f37f91d23f0bc602a783.NginxMailingListRussian@forum.nginx.org>

нашел!... получаеться предыдущий редирект со схожим названием перехватывает
и формирует неправильную ссылку (

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


From nginx-forum на forum.nginx.org  Wed Jul 29 08:56:56 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Wed, 29 Jul 2020 04:56:56 -0400
Subject: =?UTF-8?B?UmU6IFNTTCDQtNC70Y8gSUUgOA==?=
In-Reply-To: <CAFHpkQH5fRABJAJkAKg7UxSskPogfKeOWDw_C=gCcOO+JH4wSg@mail.gmail.com>
References: <CAFHpkQH5fRABJAJkAKg7UxSskPogfKeOWDw_C=gCcOO+JH4wSg@mail.gmail.com>
Message-ID: <0e34a95b1f5f248cb6b763897e242c55.NginxMailingListRussian@forum.nginx.org>

Не было времени посмотреть?

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


From mihakot на gmail.com  Fri Jul 31 11:14:17 2020
From: mihakot на gmail.com (MihaKot)
Date: Fri, 31 Jul 2020 14:14:17 +0300
Subject: =?UTF-8?B?0J3QtSDQutC+0YDRgNC10LrRgtC90L4g0YDQsNCx0L7RgtCw0LXRgiByb290INCy?=
 =?UTF-8?B?IG5naW54?=
Message-ID: <CAB_7BgrNH2ySHTcDMN_TM-toQb95RP_+S-NHLU7Mu3FNkEty-Q@mail.gmail.com>

есть конфигурация nginx

server {
    listen       80;
    server_name  client.test.domain;

    charset utf-8;

    root /var/www/_test.domain/client/;
    index  index.php index.html;

    client_max_body_size 0;

    location / {
        #root /var/www/_test.domain/client/;
    }
    location /html {
        #root /var/www/_test.domain/;
        alias /var/www/_test.domain/html;
    }

    location ~ \.php$ {
        fastcgi_pass   unix:/var/run/php-www.sock;
        #fastcgi_pass 127.0.0.1.:9000;
        fastcgi_index index.php;
        fastcgi_buffer_size 64k;
        fastcgi_buffers 4 64k;
        include fastcgi_params;
        fastcgi_param HTTPS on;
        fastcgi_param SCRIPT_FILENAME
/var/www/_test.domain/client$fastcgi_script_name;
        #fastcgi_param PHP_ADMIN_VALUE
"open_basedir=/var/www:/tmp:/var/lib/sessions:/var/www/tmp:/var/www/log";
        #include /etc/nginx/fastcgi_params;
    }


    location ~* /(images|cache|media|logs|tmp)/.*\.(php|pl|py|jsp|asp|sh|cgi)$ {
        return 403;
        error_page 403 /403_error.html;
    }

    # caching of files
    location ~* \.(ico|pdf|flv)$ {
        expires 1y;
    }
    location ~* \.(js|css|png|jpg|jpeg|gif|swf|xml|txt)$ {
        expires 14d;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }}

При такой конфигурации скрипты работают, при запросе
client.test.domain/html/css/style.css выдает 404 Not found

в логе nginx видно что файл ищет
"/var/www/_test.domain/client/html/css/style.css"

если же сделать так

    #root /var/www/_test.domain/client/;
    index  index.php index.html;

    client_max_body_size 0;

    location / {
        root /var/www/_test.domain/client/;
    }
    location /html {
        #root /var/www/_test.domain/;
        alias /var/www/_test.domain/html;
    }

то он пытается найти файл в "/etc/nginx/html/html/css/style.css"

замена на root тоже игнорируется.


    location /html { root /var/www/_test.domain/; #alias /var/www/_test.
domain/html; }

пытается найти файл по "/var/www/_test.domain/client/html/css/style.css"


я уже сломал весь мозг. Потому как в документации сказано что root и alias
 в location должно работать.

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

From bgx на protva.ru  Fri Jul 31 12:05:18 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Fri, 31 Jul 2020 15:05:18 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0LrQvtGA0YDQtdC60YLQvdC+INGA0LDQsdC+0YLQsNC10YIgcm9v?=
 =?UTF-8?B?dCDQsiBuZ2lueA==?=
In-Reply-To: <CAB_7BgrNH2ySHTcDMN_TM-toQb95RP_+S-NHLU7Mu3FNkEty-Q@mail.gmail.com>
References: <CAB_7BgrNH2ySHTcDMN_TM-toQb95RP_+S-NHLU7Mu3FNkEty-Q@mail.gmail.com>
Message-ID: <20200731120518.GC15598@sie.protva.ru>

On Fri, Jul 31, 2020 at 02:14:17PM +0300, MihaKot wrote:
>    есть конфигурация nginx
> 
>  server {
>      listen       80;
>      server_name  client.test.domain;
> 
>      charset utf-8;
> 
>      root /var/www/_test.domain/client/;
>      index  index.php index.html;
> 
>      client_max_body_size 0;
> 
>      location / {
>          #root /var/www/_test.domain/client/;
>      }
>      location /html {
>          #root /var/www/_test.domain/;
>          alias /var/www/_test.domain/html;
>      }
...
>      location ~* \.(js|css|png|jpg|jpeg|gif|swf|xml|txt)$ {
>          expires 14d;
>      }
...
>    При такой конфигурации скрипты работают, при
>    запросе client.test.domain/html/css/style.css выдает 404 Not found
> 
>    в логе nginx видно что файл
>    ищет "/var/www/_test.domain/client/html/css/style.css"

 Всё правильно: срабатывает последний процитированный локейшн, а так
 как root для него не переопределён, он наследуется от блока server.

 В документации по директиве location описан алгоритм выбора конкретного
 блока: http://nginx.org/en/docs/http/ngx_http_core_module.html#location
-- 
 Eugene Berdnikov

From mdounin на mdounin.ru  Fri Jul 31 12:09:56 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Fri, 31 Jul 2020 15:09:56 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0LrQvtGA0YDQtdC60YLQvdC+INGA0LDQsdC+0YLQsNC10YIgcm9v?=
 =?UTF-8?B?dCDQsiBuZ2lueA==?=
In-Reply-To: <CAB_7BgrNH2ySHTcDMN_TM-toQb95RP_+S-NHLU7Mu3FNkEty-Q@mail.gmail.com>
References: <CAB_7BgrNH2ySHTcDMN_TM-toQb95RP_+S-NHLU7Mu3FNkEty-Q@mail.gmail.com>
Message-ID: <20200731120956.GI12747@mdounin.ru>

Hello!

On Fri, Jul 31, 2020 at 02:14:17PM +0300, MihaKot wrote:

> есть конфигурация nginx
> 
> server {

[...]

>     root /var/www/_test.domain/client/;

[...]

>     location /html {

[...]

>     location ~* \.(js|css|png|jpg|jpeg|gif|swf|xml|txt)$ {
>         expires 14d;
>     }

[...]

> При такой конфигурации скрипты работают, при запросе
> client.test.domain/html/css/style.css выдает 404 Not found
> 
> в логе nginx видно что файл ищет
> "/var/www/_test.domain/client/html/css/style.css"

Всё правильно, какой root указан - такой и используется.

Важно для понимания: для обработки запроса используется строго 
один location, и если вы себе сделали location "для статики", в 
который попадает запрос, то действует тот root, который задан в 
этом location'е.

Если хочется, чтобы работала конфигурация из "location /html", то 
есть два пути:

1. Запретить проверять регулярные выражения после "location 
/html", добавив модификатор "^~".

2. Изолировать имеющиеся регулярные выражения там, где они должны 
применяться, например - внутри "location /".

[...]

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

From mihakot на gmail.com  Fri Jul 31 12:36:30 2020
From: mihakot на gmail.com (MihaKot)
Date: Fri, 31 Jul 2020 15:36:30 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0LrQvtGA0YDQtdC60YLQvdC+INGA0LDQsdC+0YLQsNC10YIgcm9v?=
 =?UTF-8?B?dCDQsiBuZ2lueA==?=
In-Reply-To: <20200731120956.GI12747@mdounin.ru>
References: <CAB_7BgrNH2ySHTcDMN_TM-toQb95RP_+S-NHLU7Mu3FNkEty-Q@mail.gmail.com>
 <20200731120956.GI12747@mdounin.ru>
Message-ID: <CAB_7BgrtB2=aExY-jyNJLVZaqRBkV=EEW52vwXXW+MBptj3qig@mail.gmail.com>

> 1. Запретить проверять регулярные выражения после "location /html",
добавив модификатор "^~"

 Спасибо! помогло

пт, 31 июл. 2020 г. в 15:10, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Fri, Jul 31, 2020 at 02:14:17PM +0300, MihaKot wrote:
>
> > есть конфигурация nginx
> >
> > server {
>
> [...]
>
> >     root /var/www/_test.domain/client/;
>
> [...]
>
> >     location /html {
>
> [...]
>
> >     location ~* \.(js|css|png|jpg|jpeg|gif|swf|xml|txt)$ {
> >         expires 14d;
> >     }
>
> [...]
>
> > При такой конфигурации скрипты работают, при запросе
> > client.test.domain/html/css/style.css выдает 404 Not found
> >
> > в логе nginx видно что файл ищет
> > "/var/www/_test.domain/client/html/css/style.css"
>
> Всё правильно, какой root указан - такой и используется.
>
> Важно для понимания: для обработки запроса используется строго
> один location, и если вы себе сделали location "для статики", в
> который попадает запрос, то действует тот root, который задан в
> этом location'е.
>
> Если хочется, чтобы работала конфигурация из "location /html", то
> есть два пути:
>
> 1. Запретить проверять регулярные выражения после "location
> /html", добавив модификатор "^~".
>
> 2. Изолировать имеющиеся регулярные выражения там, где они должны
> применяться, например - внутри "location /".
>
> [...]
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru



-- 
P.S. Сохраняйте переписку в теле письма.
___________________________________
Best regards, Konstantin @MihaKot@ Aksarin.
Phone: +7 921 74 66 818
Skype: mihakot
E-mail: mihakot на gmail.com
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200731/a3d1f93e/attachment.htm>