From gmm на csdoc.com  Sun Mar  1 06:39:04 2020
From: gmm на csdoc.com (Gena Makhomed)
Date: Sun, 1 Mar 2020 08:39:04 +0200
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?=
 =?UTF-8?B?INCyIGNlbnRvcyA4?=
In-Reply-To: <6cd59cc47f00a9238784882612ce47ac.NginxMailingListRussian@forum.nginx.org>
References: <20200229132928.GS1422@sie.protva.ru>
 <10971e10c1bf6767cfdf5153a9519860.NginxMailingListRussian@forum.nginx.org>
 <6cd59cc47f00a9238784882612ce47ac.NginxMailingListRussian@forum.nginx.org>
Message-ID: <afc9d379-7686-816c-e369-5dcc8058772c@csdoc.com>

On 29.02.2020 17:34, windos321 wrote:

> Перебрал все возможные юниты, network-scripts...

Скорее всего, у Вас там DHCP и скорее всего - Вы не пробовали

https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html

как Вам это рекомендовал сделать Алексей в этом списке рассылки.

-------- Forwarded Message --------
Subject: Re: Проблема с перезапуском в centos 8
Date: Sat, 29 Feb 2020 00:07:42 +0300
From: Alexey <ngnx8810773a83 на avksrv.org>
Reply-To: nginx-ru на nginx.org
To: nginx-ru на nginx.org

cat /etc/systemd/system/multi-user.target.wants/nginx.service

там точно есть
After= ... network-online.target ... nss-lookup.target ...
Wants= network-online.target

?

systemctl daemon-reload
после правки /usr/lib/systemd/system/nginx.service делался ?

точно эта же проблемы была на 7 центоси пускаемой в контейнере, и жалобы 
на чтото типы юбунты тоже были. Проблема в том, что systemd сильна 
асинхронно пускает все сервисы, и нгинкс успевает стартануть до сети, и 
обламывается потому, что до ресловера достутчаться нельзя.. при 
network-online.target и nss-lookup.target ресолв должен работать бы... у 
вас часом адреса не по DHCP ?

если DHCP,  можно затычку вида
https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html
и зависимость от него...

-- 
Best regards,
  Gena


From nginx-forum на forum.nginx.org  Sun Mar  1 10:52:15 2020
From: nginx-forum на forum.nginx.org (windos321)
Date: Sun, 01 Mar 2020 05:52:15 -0500
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?=
 =?UTF-8?B?INCyIGNlbnRvcyA4?=
In-Reply-To: <afc9d379-7686-816c-e369-5dcc8058772c@csdoc.com>
References: <afc9d379-7686-816c-e369-5dcc8058772c@csdoc.com>
Message-ID: <d7c8de7b296ae7a10e59b54fde9851b4.NginxMailingListRussian@forum.nginx.org>

Был DHCP изначально, но перенастройка на static не помогает.

 https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html
Здесь говорится о systemd-networkd-wait-online.service
По умолчанию в centos 8 его нету.

Зато есть NetworkManager-wait-online.service

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


From nginx-forum на forum.nginx.org  Sun Mar  1 11:28:47 2020
From: nginx-forum на forum.nginx.org (windos321)
Date: Sun, 01 Mar 2020 06:28:47 -0500
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?=
 =?UTF-8?B?INCyIGNlbnRvcyA4?=
In-Reply-To: <ef65dbea6f92b994a2ad8e73ebbf7b70.NginxMailingListRussian@forum.nginx.org>
References: <ef65dbea6f92b994a2ad8e73ebbf7b70.NginxMailingListRussian@forum.nginx.org>
Message-ID: <294520d78f5f3ba3c3fe6626af9f1791.NginxMailingListRussian@forum.nginx.org>

Короче все дело было вот здесь:
/usr/lib/systemd/system/NetworkManager-wait-online.service
убрать параметр -s, который почему-то по умолчанию стоит в centos 8
с этим параметром centos 8 не ждет подключения к сети, ей достаточно запуска
network manager

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


From chipitsine на gmail.com  Mon Mar  2 07:41:58 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 2 Mar 2020 12:41:58 +0500
Subject: =?UTF-8?B?0LfQtdGA0LrQsNC70LjRgNC+0LLQsNC90LjQtSBVRFAg0YLRgNCw0YTQuNC60LA=?=
Message-ID: <CAFHpkQHwdEYuAWYJknW3aADrx2coJ=iT+xXsnfp4RjJxLWn0ww@mail.gmail.com>

привет!

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

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

некостыльных вариантов нет ?

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

From boco на ufanet.ru  Mon Mar  2 07:45:17 2020
From: boco на ufanet.ru (damir bikmuhametov)
Date: Mon, 2 Mar 2020 12:45:17 +0500
Subject: =?UTF-8?B?UmU6INC30LXRgNC60LDQu9C40YDQvtCy0LDQvdC40LUgVURQINGC0YDQsNGE0Lg=?=
 =?UTF-8?B?0LrQsA==?=
In-Reply-To: <CAFHpkQHwdEYuAWYJknW3aADrx2coJ=iT+xXsnfp4RjJxLWn0ww@mail.gmail.com>
References: <CAFHpkQHwdEYuAWYJknW3aADrx2coJ=iT+xXsnfp4RjJxLWn0ww@mail.gmail.com>
Message-ID: <20200302074517.GP24754@ufanet.ru>

On Mon, Mar 02, 2020 at 12:41:58PM +0500, Илья Шипицин wrote:
> хочется странного - продублировать udp трафик на несколько ендпойтов в
> режиме "ответа не предполагается".

https://github.com/sleinen/samplicator =)

-- 
boco

From chipitsine на gmail.com  Mon Mar  2 07:50:15 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 2 Mar 2020 12:50:15 +0500
Subject: =?UTF-8?B?UmU6INC30LXRgNC60LDQu9C40YDQvtCy0LDQvdC40LUgVURQINGC0YDQsNGE0Lg=?=
 =?UTF-8?B?0LrQsA==?=
In-Reply-To: <20200302074517.GP24754@ufanet.ru>
References: <CAFHpkQHwdEYuAWYJknW3aADrx2coJ=iT+xXsnfp4RjJxLWn0ww@mail.gmail.com>
 <20200302074517.GP24754@ufanet.ru>
Message-ID: <CAFHpkQGcM1k9xVNWQJ4gQZ8DLJX3jGPXxhETBqaMkfmpOeH4xg@mail.gmail.com>

пн, 2 мар. 2020 г. в 12:45, damir bikmuhametov <boco на ufanet.ru>:

> On Mon, Mar 02, 2020 at 12:41:58PM +0500, Илья Шипицин wrote:
> > хочется странного - продублировать udp трафик на несколько ендпойтов в
> > режиме "ответа не предполагается".
>
> https://github.com/sleinen/samplicator =)
>

да, эта штука в шортлисте.


>
> --
> boco
> _______________________________________________
> 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/20200302/c8908ace/attachment.htm>

From andrey на kopeyko.ru  Mon Mar  2 10:12:56 2020
From: andrey на kopeyko.ru (Andrey Kopeyko)
Date: Mon, 02 Mar 2020 13:12:56 +0300
Subject: =?UTF-8?B?UmU6INC30LXRgNC60LDQu9C40YDQvtCy0LDQvdC40LUgVURQINGC0YDQsNGE0Lg=?=
 =?UTF-8?B?0LrQsA==?=
In-Reply-To: <CAFHpkQHwdEYuAWYJknW3aADrx2coJ=iT+xXsnfp4RjJxLWn0ww@mail.gmail.com>
References: <CAFHpkQHwdEYuAWYJknW3aADrx2coJ=iT+xXsnfp4RjJxLWn0ww@mail.gmail.com>
Message-ID: <f0b980586211794eab04cc758d804f6d@kopeyko.ru>

Илья Шипицин писал 2020-03-02 10:41:
> привет!
> 
> хочется странного - продублировать udp
> трафик на несколько ендпойтов в
> режиме "ответа не предполагается".
> 
> придумался костыльный вариант -
> проксировать якобы с ожиданием
> ответа, и в случае, если ответа не было
> (а его не будет), проксировать на
> следующий.
> 
> некостыльных вариантов нет ?

Пропатчить http://nginx.org/ru/docs/http/ngx_http_mirror_module.html
на предмет работы с UDP ?


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

From kpoxa на kpoxa.net  Mon Mar  2 11:02:20 2020
From: kpoxa на kpoxa.net (kpoxa)
Date: Mon, 2 Mar 2020 14:02:20 +0300
Subject: =?UTF-8?B?UmU6INCb0L7Qs9Cz0LjRgNC+0LLQsNC90LjQtSDQutC+0L3QvdC10LrRgtC+0LIg?=
 =?UTF-8?B?0LHQtdC3INC30LDQv9GA0L7RgdC+0LI=?=
In-Reply-To: <20200227122245.GF12894@mdounin.ru>
References: <CABL5twCao7tohx+kCYLe=a_tP5EpzTwqixhtxMsDsJobHpEgZg@mail.gmail.com>
 <20200227122245.GF12894@mdounin.ru>
Message-ID: <CABL5twCaxMTGvd2=jXMEAmxNf7itLa9hey+iRcpKdT6FZ3DW3Q@mail.gmail.com>

Добрый день.

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

чт, 27 февр. 2020 г. в 15:22, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Thu, Feb 27, 2020 at 01:08:47PM +0300, kpoxa wrote:
>
> > Браузеры часто делают коннекты без запросов, которые выглядят как "а ну
> ка
> > я сделаю коннект, мало ли что надо будет.. не.. не понадобилось, разрываю
> > коннект"
> > и информации об этом коннекте в access_log конечно же нет, но логгировать
> > такие коннекты надо. Как это можно сделать?
> > Если писать свой модуль, то в какой обработчик придёт подобная
> информация?
>
> Сейчас для http эта информация есть только на уровне debug log'а.
> И в своём модуле - её тоже никак не получить, модули в http
> начинают работать только после получения заголовков запроса.
>
> Мы пару раз задумывались над вопросом "а не добавить ли строчку в
> error log на уровне info?", вида "client X connected to Y",
> аналогично тому, что делается в mail и stream.  Но пока нет
> разумного ответа на вопрос "а надо ли это вообще кому-то".
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200302/fbabba52/attachment.htm>

From mdounin на mdounin.ru  Tue Mar  3 15:16:20 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 3 Mar 2020 18:16:20 +0300
Subject: nginx-1.17.9
Message-ID: <20200303151620.GR12894@mdounin.ru>

Изменения в nginx 1.17.9                                          03.03.2020

    *) Изменение: теперь nginx не разрешает несколько строк "Host" в
       заголовке запроса.

    *) Исправление: nginx игнорировал дополнительные строки
       "Transfer-Encoding" в заголовке запроса.

    *) Исправление: утечки сокетов при использовании HTTP/2.

    *) Исправление: в рабочем процессе мог произойти segmentation fault,
       если использовался OCSP stapling.

    *) Исправление: в модуле ngx_http_mp4_module.

    *) Исправление: при перенаправлении ошибок с кодом 494 с помощью
       директивы error_page nginx возвращал ответ с кодом 494 вместо 400.

    *) Исправление: утечки сокетов при использовании подзапросов в модуле
       njs и директивы aio.


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

From nginx-forum на forum.nginx.org  Thu Mar  5 11:30:01 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Thu, 05 Mar 2020 06:30:01 -0500
Subject: =?UTF-8?B?SFRUUC8xLjEgNDAwIEJhZCBSZXF1ZXN0INC/0YDQuCDRgNC10YHRgtGA0LjQvNC1?=
 =?UTF-8?B?INCw0YPQtNC40L4g0L/QvtGC0L7QutCw?=
Message-ID: <b066d100644df8abab148bf127810a1e.NginxMailingListRussian@forum.nginx.org>

Делаю рестрим с локального сервера средствами nginx: 

        location /radio { 
              proxy_pass http://192.168.0.3:8000/128kbit.mp3;
               proxy_redirect     off;
               proxy_set_header Host $host;
               proxy_set_header X-Real-IP $remote_addr;
               proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

Если зайти на сайт по адресу test.com/radio - радио играет как положено.

Откуда тогда берется ошибка?

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


From nginx-forum на forum.nginx.org  Thu Mar  5 19:15:28 2020
From: nginx-forum на forum.nginx.org (mikhal123)
Date: Thu, 05 Mar 2020 14:15:28 -0500
Subject: [crit] SSL_read_early_data() failed
In-Reply-To: <b4d2d0125e98a7ec218eb9b454150a39.NginxMailingListRussian@forum.nginx.org>
References: <b4d2d0125e98a7ec218eb9b454150a39.NginxMailingListRussian@forum.nginx.org>
Message-ID: <43f96925ee960e21787a321decaff327.NginxMailingListRussian@forum.nginx.org>

В коллекцию "критических" для nginx ошибок:

2020/03/05 18:52:12 [crit] 2112#2112: *1715715 SSL_write() failed while
processing HTTP/2 connection, client: ip_адрес_клиента

2020/03/05 19:51:36 [crit] 2107#2107: *1814649 SSL_write() failed while
sending response to client, client: ip_адрес_клиента

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


From nginx-forum на forum.nginx.org  Wed Mar 11 14:19:56 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Wed, 11 Mar 2020 10:19:56 -0400
Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?=
 =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?=
In-Reply-To: <b066d100644df8abab148bf127810a1e.NginxMailingListRussian@forum.nginx.org>
References: <b066d100644df8abab148bf127810a1e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <9c79fcdae5f44bcc08531f75a3f4c32f.NginxMailingListRussian@forum.nginx.org>

Может быть это поможет в локализации проблемы.

На локальном сервере 192.168.0.3 вещает Icecast. Если подключиться к нему
напрямую, то он отдает заголовки:

HTTP/1.0 200 OK
Content-Type: audio/mpeg
icy-br:128
ice-audio-info: bitrate=128;channels=2;samplerate=44100
icy-description:тут описание радиостанции длиной 145 символов на
английском.
icy-genre:Information and music
icy-name:radio test.
icy-pub:0
icy-url:https://test.ru
Server: Icecast 2.3.2
Cache-Control: no-cache

Если же подключаться с нему через nginx-ректрансляцию, то nginx сообщает о
ошибке HTTP/1.1 400 Bad Request.

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


From nginx-forum на forum.nginx.org  Wed Mar 11 15:13:35 2020
From: nginx-forum на forum.nginx.org (Dmytro Lavryk)
Date: Wed, 11 Mar 2020 11:13:35 -0400
Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?=
 =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?=
In-Reply-To: <9c79fcdae5f44bcc08531f75a3f4c32f.NginxMailingListRussian@forum.nginx.org>
References: <b066d100644df8abab148bf127810a1e.NginxMailingListRussian@forum.nginx.org>
 <9c79fcdae5f44bcc08531f75a3f4c32f.NginxMailingListRussian@forum.nginx.org>
Message-ID: <3b95d388a7e2a896c50e980376c8b5e7.NginxMailingListRussian@forum.nginx.org>

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

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


From nginx-forum на forum.nginx.org  Wed Mar 11 17:12:08 2020
From: nginx-forum на forum.nginx.org (suberjin)
Date: Wed, 11 Mar 2020 13:12:08 -0400
Subject: =?UTF-8?B?0JHQu9C+0LrQuNGA0L7QstCw0L3QuNC1INC00L7RgdGC0YPQv9CwINGBIGN1c3Rv?=
 =?UTF-8?B?bSBlcnJvciBwYWdl?=
Message-ID: <d998edd87cf7b0d08013a6ab8a747d3a.NginxMailingListRussian@forum.nginx.org>

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

Я хотел бы заблокировать доступ к сайту по geoip признаку. При этом, мне бы
хотелось возвращать стилизированную картинку. 

я это вижу как-то так:

        if ($allowed_country = no) {
           return 403;
           error_page 403 /errors/deny.html;
        }

В самом конфиге много location-ов. Я не хотел бы копировать этот код во все
из них.
Алетрнатива - указать его глобально, но тогда я не могу использовать в блоке
if -  "error_page 403 /pages/unavailable.html; " Эту директиву нельзя
использовать в том контексте.

В итоге у меня получается или указать блокирование глобально в директиве
server, но без красивой ошибки или копировать код во все location-ы

Конфиг выглядит примерно так:


server {
    listen 443 ssl http2;      ## listen for ipv4
    listen [::]:443 ssl http2; ## listen for ipv6
   
    server_name example.com;

    root        /var/www/html/
   
   location / {
       if ($allowed_country = no) {
         return 403;
         error_page 403 /pages/unavailable.html;
       }
   }

   location = /admin {
     try_files $uri /index.php$is_args$args;
           
       if ($allowed_country = no) {
         return 403;
         error_page 403 /pages/unavailable.html;
       }

     }

     
    location  /errors/ {
       root /var/www/html/errors/;
       internal;
    }
     
}

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

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


From andrey на kopeyko.ru  Wed Mar 11 19:25:04 2020
From: andrey на kopeyko.ru (Andrey Kopeyko)
Date: Wed, 11 Mar 2020 22:25:04 +0300
Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQsNC90LjQtSDQtNC+0YHRgtGD0L/QsCDRgSBj?=
 =?UTF-8?B?dXN0b20gZXJyb3IgcGFnZQ==?=
In-Reply-To: <d998edd87cf7b0d08013a6ab8a747d3a.NginxMailingListRussian@forum.nginx.org>
References: <d998edd87cf7b0d08013a6ab8a747d3a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <8ffe3d8cd204a3047571a32cb86ab0f6@kopeyko.ru>

suberjin писал 2020-03-11 20:12:
> Здравствуйте.

Добрый вечер!

> Я хотел бы заблокировать доступ к сайту по geoip признаку. При этом, 
> мне бы
> хотелось возвращать стилизированную картинку.
> 
> я это вижу как-то так:
> 
>         if ($allowed_country = no) {
>            return 403;
>            error_page 403 /errors/deny.html;
>         }
> 
> В самом конфиге много location-ов. Я не хотел бы копировать этот код во 
> все из них.

Вынесите этот фрагмент в кусочек конфига, и инклудьте его в нужных 
местах.


> Подозреваю, что я что-то не так делаю. Прошу помочь. Спасибо!


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

From andrey на kopeyko.ru  Wed Mar 11 19:27:59 2020
From: andrey на kopeyko.ru (Andrey Kopeyko)
Date: Wed, 11 Mar 2020 22:27:59 +0300
Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQsNC90LjQtSDQtNC+0YHRgtGD0L/QsCDRgSBj?=
 =?UTF-8?B?dXN0b20gZXJyb3IgcGFnZQ==?=
In-Reply-To: <8ffe3d8cd204a3047571a32cb86ab0f6@kopeyko.ru>
References: <d998edd87cf7b0d08013a6ab8a747d3a.NginxMailingListRussian@forum.nginx.org>
 <8ffe3d8cd204a3047571a32cb86ab0f6@kopeyko.ru>
Message-ID: <46b62fd6ab5aa4b9861814e642bf3f5c@kopeyko.ru>

Andrey Kopeyko писал 2020-03-11 22:25:
> suberjin писал 2020-03-11 20:12:
>> Здравствуйте.
> 
> Добрый вечер!
> 
>> Я хотел бы заблокировать доступ к сайту по geoip признаку. При этом, 
>> мне бы
>> хотелось возвращать стилизированную картинку.
>> 
>> я это вижу как-то так:
>> 
>>         if ($allowed_country = no) {
>>            return 403;
>>            error_page 403 /errors/deny.html;
>>         }
>> 
>> В самом конфиге много location-ов. Я не хотел бы копировать этот код 
>> во все из них.
> 
> Вынесите этот фрагмент в кусочек конфига, и инклудьте его в нужных 
> местах.

Другой вариант - генерируйте ваш конфиг с нужными проверками в каждом из 
локейшенов.


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

From nginx-forum на forum.nginx.org  Wed Mar 11 19:35:05 2020
From: nginx-forum на forum.nginx.org (suberjin)
Date: Wed, 11 Mar 2020 15:35:05 -0400
Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQsNC90LjQtSDQtNC+0YHRgtGD0L/QsCDRgSBj?=
 =?UTF-8?B?dXN0b20gZXJyb3IgcGFnZQ==?=
In-Reply-To: <46b62fd6ab5aa4b9861814e642bf3f5c@kopeyko.ru>
References: <46b62fd6ab5aa4b9861814e642bf3f5c@kopeyko.ru>
Message-ID: <60371d8222d33a886c232f9caf3bca93.NginxMailingListRussian@forum.nginx.org>

Спасибо за совет! Похоже, что Include - оптимальный вариант. Я сначала
думал, может я по незнанию упустил какой-то нативный способ.

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


From oleg на mamontov.net  Wed Mar 11 19:52:46 2020
From: oleg на mamontov.net (Oleg A. Mamontov)
Date: Wed, 11 Mar 2020 22:52:46 +0300
Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQsNC90LjQtSDQtNC+0YHRgtGD0L/QsCDRgSBj?=
 =?UTF-8?B?dXN0b20gZXJyb3IgcGFnZQ==?=
In-Reply-To: <d998edd87cf7b0d08013a6ab8a747d3a.NginxMailingListRussian@forum.nginx.org>
References: <d998edd87cf7b0d08013a6ab8a747d3a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200311195246.e5yvv6jbepgwxqhz@xenon.mamontov.net>

On Wed, Mar 11, 2020 at 01:12:08PM -0400, suberjin wrote:
>Здравствуйте.
>
>Я хотел бы заблокировать доступ к сайту по geoip признаку. При этом, мне бы
>хотелось возвращать стилизированную картинку.
>
>я это вижу как-то так:
>
>        if ($allowed_country = no) {
>           return 403;
>           error_page 403 /errors/deny.html;
>        }
>
>В самом конфиге много location-ов. Я не хотел бы копировать этот код во все
>из них.
>Алетрнатива - указать его глобально, но тогда я не могу использовать в блоке
>if -  "error_page 403 /pages/unavailable.html; " Эту директиву нельзя
>использовать в том контексте.
>
>В итоге у меня получается или указать блокирование глобально в директиве
>server, но без красивой ошибки или копировать код во все location-ы

Вот такой вариант вам не подойдет?
---
server {
    listen 80;
    server_name example.com;

    if ( $allowed_country = no ) {
        set $allowed_country yes;  # breaking loop
        rewrite ^ /deny last;
    }

    location / {
        proxy_pass http://backend;
    }
    location = /deny {
        internal;
        error_page 403 /errors/deny.html;
        return 403;
    }
    location /errors/ {
        internal;
        root /var/www/html;
    }
}
---

Может и не образец красоты, но работать должно.

>Конфиг выглядит примерно так:
>
>
>server {
>    listen 443 ssl http2;      ## listen for ipv4
>    listen [::]:443 ssl http2; ## listen for ipv6
>
>    server_name example.com;
>
>    root        /var/www/html/
>
>   location / {
>       if ($allowed_country = no) {
>         return 403;
>         error_page 403 /pages/unavailable.html;
>       }
>   }
>
>   location = /admin {
>     try_files $uri /index.php$is_args$args;
>
>       if ($allowed_country = no) {
>         return 403;
>         error_page 403 /pages/unavailable.html;
>       }
>
>     }
>
>
>    location  /errors/ {
>       root /var/www/html/errors/;
>       internal;
>    }
>
>}
>
>Подозреваю, что я что-то не так делаю. Прошу помочь. Спасибо!
>
>Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287292,287292#msg-287292
>
>_______________________________________________
>nginx-ru mailing list
>nginx-ru на nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Cheers,
Oleg A. Mamontov

mailto: oleg на mamontov.net

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

From nginx-forum на forum.nginx.org  Thu Mar 12 06:32:23 2020
From: nginx-forum на forum.nginx.org (inkognito0609)
Date: Thu, 12 Mar 2020 02:32:23 -0400
Subject: UDP Connection refused
Message-ID: <f60cc8ad5d2bd100dd132d418745d8eb.NginxMailingListRussian@forum.nginx.org>

При отправке логов через syslog (udp) проскакивают ошибки 111 Connection
refused, что непонятно при отправке логов по udp, так как этот протокол не
подразумевает установки соединения в принципе.

strace дает следующее:
30752 sendto(64, "<190>Mar 12 09:45:59 balancer nginx: { \"timestamp\":
\"2020-03-12T09:45:59+05:00\", \"remote_addr\": \"91.144.134.5\",
\"body_bytes_sent\": 18686, \"request_time\": 0.000, \"response_status\":
200, \"request\": \"GET /themes/default/images/flags.png HTTP/1.0\",
\"request_method\": \"GET\", \"host\":
\"chel.wifi.example.ru\",\"upstream_cache_status\":
\"HIT\",\"upstream_addr\": \"\",\"http_x_forwarded_for\":
\"10.12.199.134\",\"http_referrer\":
\"https://chel.wifi.domru.ru/index.php?request_uri=http://captive.apple.com/hotspot-detect.html\",
\"upstream_response_time\": \"\",\"upstream_header_time\":
\"\",\"upstream_connect_time\": \"\",\"http_user_agent\": \"Mozilla/5.0
(Macintosh; Intel Mac OS X 10_14) AppleWebKit/605.1.15 (KHTML, like
Gecko)\",\"x-project\": \"\",\"cluster\": \"1\",\"container_id\":
\"\",\"citydomain\": \"\" }", 765, 0, NULL, 0) = -1 ECONNREFUSED (Connection
refused)

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


From nginx-forum на forum.nginx.org  Thu Mar 12 08:01:57 2020
From: nginx-forum на forum.nginx.org (suberjin)
Date: Thu, 12 Mar 2020 04:01:57 -0400
Subject: =?UTF-8?B?UmU6INCR0LvQvtC60LjRgNC+0LLQsNC90LjQtSDQtNC+0YHRgtGD0L/QsCDRgSBj?=
 =?UTF-8?B?dXN0b20gZXJyb3IgcGFnZQ==?=
In-Reply-To: <20200311195246.e5yvv6jbepgwxqhz@xenon.mamontov.net>
References: <20200311195246.e5yvv6jbepgwxqhz@xenon.mamontov.net>
Message-ID: <7ac43d7117d92671f416e369e0dd99de.NginxMailingListRussian@forum.nginx.org>

то что нужно, работает великолепно!
Очень признателен за помощь!

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


From nginx-forum на forum.nginx.org  Thu Mar 12 09:33:37 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Thu, 12 Mar 2020 05:33:37 -0400
Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?=
 =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?=
In-Reply-To: <3b95d388a7e2a896c50e980376c8b5e7.NginxMailingListRussian@forum.nginx.org>
References: <b066d100644df8abab148bf127810a1e.NginxMailingListRussian@forum.nginx.org>
 <9c79fcdae5f44bcc08531f75a3f4c32f.NginxMailingListRussian@forum.nginx.org>
 <3b95d388a7e2a896c50e980376c8b5e7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <763781c973fac6445799e57440b8e8de.NginxMailingListRussian@forum.nginx.org>

Ошибки как таковой нету, есть не верный код возврата заголовка.

Делаю именно GET, получаю ответ:

HTTP/1.1 400 Bad Request
Server: nginx
Date: Thu, 12 Mar 2020 09:31:23 GMT
Content-Type: text/html
Content-Length: 248
Connection: close

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


From chipitsine на gmail.com  Thu Mar 12 09:44:40 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 12 Mar 2020 14:44:40 +0500
Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?=
 =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?=
In-Reply-To: <763781c973fac6445799e57440b8e8de.NginxMailingListRussian@forum.nginx.org>
References: <b066d100644df8abab148bf127810a1e.NginxMailingListRussian@forum.nginx.org>
 <9c79fcdae5f44bcc08531f75a3f4c32f.NginxMailingListRussian@forum.nginx.org>
 <3b95d388a7e2a896c50e980376c8b5e7.NginxMailingListRussian@forum.nginx.org>
 <763781c973fac6445799e57440b8e8de.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQH5rtPBDUZTXuunx3gZEfybs7FyOQbtJMJNQmG=apDsWQ@mail.gmail.com>

попробуйте дебажную сборку nginx и error.log в режиме debug

чт, 12 мар. 2020 г. в 14:33, grey <nginx-forum на forum.nginx.org>:

> Ошибки как таковой нету, есть не верный код возврата заголовка.
>
> Делаю именно GET, получаю ответ:
>
> HTTP/1.1 400 Bad Request
> Server: nginx
> Date: Thu, 12 Mar 2020 09:31:23 GMT
> Content-Type: text/html
> Content-Length: 248
> Connection: close
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,287264,287310#msg-287310
>
> _______________________________________________
> 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/20200312/f528879a/attachment.htm>

From bgx на protva.ru  Thu Mar 12 09:51:42 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Thu, 12 Mar 2020 12:51:42 +0300
Subject: UDP Connection refused
In-Reply-To: <f60cc8ad5d2bd100dd132d418745d8eb.NginxMailingListRussian@forum.nginx.org>
References: <f60cc8ad5d2bd100dd132d418745d8eb.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200312095142.GA2894@protva.ru>

On Thu, Mar 12, 2020 at 02:32:23AM -0400, inkognito0609 wrote:
> При отправке логов через syslog (udp) проскакивают ошибки 111 Connection
> refused, что непонятно при отправке логов по udp, так как этот протокол не
> подразумевает установки соединения в принципе.

 Читайте man 7 udp. ECONNREFUSED может быть вызвана отображением
 на уровень сокетов ответов icmp[port-unreach], icmp[admin-prohib]
 на предыдущие пакеты от этого сокета, а также блокировкой исходящих udp
 локальным пакетным фильтром. Конкретика зависит от реализации
 (может отличаться для разных ОС). К nginx это отношения не имеет.
-- 
 Eugene Berdnikov

From mdounin на mdounin.ru  Thu Mar 12 12:34:03 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 12 Mar 2020 15:34:03 +0300
Subject: UDP Connection refused
In-Reply-To: <f60cc8ad5d2bd100dd132d418745d8eb.NginxMailingListRussian@forum.nginx.org>
References: <f60cc8ad5d2bd100dd132d418745d8eb.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200312123403.GH12894@mdounin.ru>

Hello!

On Thu, Mar 12, 2020 at 02:32:23AM -0400, inkognito0609 wrote:

> При отправке логов через syslog (udp) проскакивают ошибки 111 Connection
> refused, что непонятно при отправке логов по udp, так как этот протокол не
> подразумевает установки соединения в принципе.
> 
> strace дает следующее:
> 30752 sendto(64, "<190>Mar 12 09:45:59 balancer nginx: { \"timestamp\":
> \"2020-03-12T09:45:59+05:00\", \"remote_addr\": \"91.144.134.5\",
> \"body_bytes_sent\": 18686, \"request_time\": 0.000, \"response_status\":
> 200, \"request\": \"GET /themes/default/images/flags.png HTTP/1.0\",
> \"request_method\": \"GET\", \"host\":
> \"chel.wifi.example.ru\",\"upstream_cache_status\":
> \"HIT\",\"upstream_addr\": \"\",\"http_x_forwarded_for\":
> \"10.12.199.134\",\"http_referrer\":
> \"https://chel.wifi.domru.ru/index.php?request_uri=http://captive.apple.com/hotspot-detect.html\",
> \"upstream_response_time\": \"\",\"upstream_header_time\":
> \"\",\"upstream_connect_time\": \"\",\"http_user_agent\": \"Mozilla/5.0
> (Macintosh; Intel Mac OS X 10_14) AppleWebKit/605.1.15 (KHTML, like
> Gecko)\",\"x-project\": \"\",\"cluster\": \"1\",\"container_id\":
> \"\",\"citydomain\": \"\" }", 765, 0, NULL, 0) = -1 ECONNREFUSED (Connection
> refused)

Да, так бывает.

Цитируя "Programming UNIX Sockets in C - Frequently Asked 
Questions", AKA Socket FAQ 
(http://web.deu.edu.tr/doc/soket/#faq57):

: If the target machine discards the message because there is no 
: process reading on the requested port number, it sends an ICMP 
: message to your machine which will cause the next system call on 
: the socket to return ECONNREFUSED. Since delivery of ICMP messages 
: is not guarenteed you may not recieve this notification on the 
: first transaction.

То есть ошибка ожидаема, и она означает, что на предыдущее 
сообщение в syslog прилетело ICMP-сообщение в ответ.

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

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

From nginx-forum на forum.nginx.org  Thu Mar 12 16:54:31 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Thu, 12 Mar 2020 12:54:31 -0400
Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?=
 =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?=
In-Reply-To: <3b95d388a7e2a896c50e980376c8b5e7.NginxMailingListRussian@forum.nginx.org>
References: <b066d100644df8abab148bf127810a1e.NginxMailingListRussian@forum.nginx.org>
 <9c79fcdae5f44bcc08531f75a3f4c32f.NginxMailingListRussian@forum.nginx.org>
 <3b95d388a7e2a896c50e980376c8b5e7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <0c5768569c1b8c66ee922518759ba7d4.NginxMailingListRussian@forum.nginx.org>

Dmytro Lavryk Wrote:
-------------------------------------------------------
> Вы ошибку не описали... Но, подозреваю, делаете HEAD запрос. Проверил
> у себя на аналогичном - HEAD дает 400, а вот GET отрабатывает
> нормально со всеми нужными заголовками.

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

$fp = fsockopen("test.ru", 443, $errno, $errstr, 30);
$out = "GET /radio-stream HTTP/1.1\r\n";
$out .= "Host: test.ru\r\n";
$out .= "Connection: Close\r\n\r\n";
fwrite($fp, $out);
while (!feof($fp)) echo fgets($fp, 128);
fclose($fp);

В нем я явно указываю тип запроса GET, а nginx почему говорит что к нему
пришел HEAD и возвращает ответ "400 Bad Request". Проверил на разных версиях
php - результат везде одинаковый, т.к. вроде как дело не в нем.

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


From bgx на protva.ru  Thu Mar 12 21:29:08 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Fri, 13 Mar 2020 00:29:08 +0300
Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?=
 =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?=
In-Reply-To: <0c5768569c1b8c66ee922518759ba7d4.NginxMailingListRussian@forum.nginx.org>
References: <b066d100644df8abab148bf127810a1e.NginxMailingListRussian@forum.nginx.org>
 <9c79fcdae5f44bcc08531f75a3f4c32f.NginxMailingListRussian@forum.nginx.org>
 <3b95d388a7e2a896c50e980376c8b5e7.NginxMailingListRussian@forum.nginx.org>
 <0c5768569c1b8c66ee922518759ba7d4.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200312212908.GH14751@sie.protva.ru>

On Thu, Mar 12, 2020 at 12:54:31PM -0400, grey wrote:
> Dmytro Lavryk Wrote:
> -------------------------------------------------------
> > Вы ошибку не описали... Но, подозреваю, делаете HEAD запрос. Проверил
> > у себя на аналогичном - HEAD дает 400, а вот GET отрабатывает
> > нормально со всеми нужными заголовками.
> 
> Да, действительно, дело в типе запроса, но понять не могу почему так
> происходит. Напишу тут код на php, я думаю программистам других языков он
> будет понятен:
> 
> $fp = fsockopen("test.ru", 443, $errno, $errstr, 30);
> $out = "GET /radio-stream HTTP/1.1\r\n";
> $out .= "Host: test.ru\r\n";
> $out .= "Connection: Close\r\n\r\n";
> fwrite($fp, $out);
> while (!feof($fp)) echo fgets($fp, 128);
> fclose($fp);
> 
> В нем я явно указываю тип запроса GET, а nginx почему говорит что к нему
> пришел HEAD

 Откуда вывод, что nginx якобы видит HEAD?

> и возвращает ответ "400 Bad Request".
> Проверил на разных версиях
> php - результат везде одинаковый, т.к. вроде как дело не в нем.

 И что, вот так просто шлём plain http на 443-й порт, а nginx недоволен?
-- 
 Eugene Berdnikov

From nginx-forum на forum.nginx.org  Fri Mar 13 07:42:03 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Fri, 13 Mar 2020 03:42:03 -0400
Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?=
 =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?=
In-Reply-To: <20200312212908.GH14751@sie.protva.ru>
References: <20200312212908.GH14751@sie.protva.ru>
Message-ID: <9bf4aca8d527e1691e29e16c91de00b9.NginxMailingListRussian@forum.nginx.org>

> Откуда вывод, что nginx якобы видит HEAD?

В логах nginx видно:
95.8.*.* - - [13/Mar/2020:10:24:59 +0300] "HEAD /radio-stream HTTP/1.1" 400
0 "-" "-"

При GET запросе:
95.8.*.* - - [13/Mar/2020:10:28:45 +0300] "GET /radio-stream HTTP/1.1" 200
146900 "-" "-"

Сам php-код, коим проверяю:

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "https://test.ru/radio-stream");
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch, CURLOPT_HEADER, 1);
curl_setopt($ch, CURLOPT_NOBODY, 0); // это GET запрос
#curl_setopt($ch, CURLOPT_NOBODY, 1); // это HEAD запрос
curl_setopt($ch, CURLOPT_TIMEOUT, 5);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
$content=curl_exec ($ch);
curl_close ($ch);


> И что, вот так просто шлём plain http на 443-й порт, а nginx недоволен?

Да или я чего-то не понимаю?

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


From bgx на protva.ru  Fri Mar 13 08:06:34 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Fri, 13 Mar 2020 11:06:34 +0300
Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?=
 =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?=
In-Reply-To: <9bf4aca8d527e1691e29e16c91de00b9.NginxMailingListRussian@forum.nginx.org>
References: <20200312212908.GH14751@sie.protva.ru>
 <9bf4aca8d527e1691e29e16c91de00b9.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200313080634.GI14751@sie.protva.ru>

On Fri, Mar 13, 2020 at 03:42:03AM -0400, grey wrote:
> > Откуда вывод, что nginx якобы видит HEAD?
> 
> В логах nginx видно:
> 95.8.*.* - - [13/Mar/2020:10:24:59 +0300] "HEAD /radio-stream HTTP/1.1" 400
> 0 "-" "-"
> 
> При GET запросе:
> 95.8.*.* - - [13/Mar/2020:10:28:45 +0300] "GET /radio-stream HTTP/1.1" 200
> 146900 "-" "-"
> 
> Сам php-код, коим проверяю:
> 
> $ch = curl_init();
> curl_setopt($ch, CURLOPT_URL, "https://test.ru/radio-stream");

 Достаточно. Расстрелять. :) Это не код приложения, а вызов посторонней
 программы, которая выполняет СВОЙ код (а не тот, который цитировался),
 и вообще делает обращение с СДРУГИМ url. То есть вообще всё другое,
 а результат доказывает, что nginx работает правильно.

> > И что, вот так просто шлём plain http на 443-й порт, а nginx недоволен?
> 
> Да или я чего-то не понимаю?

 Ага. Из того, что curl работает и приводит к осмысленным записям в логе,
 следует, что plain http это совсем не то, чего ждёт nginx на этом порту.
 Подумайте над тем, что означает буква "s" в https://... :)
-- 
 Eugene Berdnikov

From nginx-forum на forum.nginx.org  Mon Mar 16 07:21:53 2020
From: nginx-forum на forum.nginx.org (grey)
Date: Mon, 16 Mar 2020 03:21:53 -0400
Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?=
 =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?=
In-Reply-To: <20200313080634.GI14751@sie.protva.ru>
References: <20200313080634.GI14751@sie.protva.ru>
Message-ID: <5b7d2906a9e3deefdcb9eb0d3183f3a9.NginxMailingListRussian@forum.nginx.org>

Хорошо, сделал по другому - нашел несколько сторонних сервисов, в которых
можно узакать УРЛ ресурса и типа запроса. Абсолютно все возвращают "HTTP/1.1
400 Bad Request". Я конечно не знаю как они работают, но неужели все такие
же косорукие как и я? :) Dmytro Lavryk тоже говорит, что у него аналогичный
код ответа при HEAD запросе.

Может все таки что-то не так настроено у меня в nginx?

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


From chipitsine на gmail.com  Mon Mar 16 07:54:33 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 16 Mar 2020 12:54:33 +0500
Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?=
 =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?=
In-Reply-To: <5b7d2906a9e3deefdcb9eb0d3183f3a9.NginxMailingListRussian@forum.nginx.org>
References: <20200313080634.GI14751@sie.protva.ru>
 <5b7d2906a9e3deefdcb9eb0d3183f3a9.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQFVaAQO8Hzp2BR5kySyyOrgNM11-Axt7WgfWb5soODKFw@mail.gmail.com>

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

еще раз - "400 bad request" во многих случаях можно подсмотреть по
error.log (на всякий случай запустите отладочную сборку nginx).
если у вас будет 400, но в error.log тишина, то вы сузили количество
возможных вариантов - можете поискать по исходному коду,
такие места, где отдается 400 втихую есть, но их мало.

пн, 16 мар. 2020 г. в 12:22, grey <nginx-forum на forum.nginx.org>:

> Хорошо, сделал по другому - нашел несколько сторонних сервисов, в которых
> можно узакать УРЛ ресурса и типа запроса. Абсолютно все возвращают
> "HTTP/1.1
> 400 Bad Request". Я конечно не знаю как они работают, но неужели все такие
> же косорукие как и я? :) Dmytro Lavryk тоже говорит, что у него аналогичный
> код ответа при HEAD запросе.
>
> Может все таки что-то не так настроено у меня в nginx?
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,287264,287355#msg-287355
>
> _______________________________________________
> 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/20200316/3a22c5c8/attachment.htm>

From mdounin на mdounin.ru  Mon Mar 16 11:57:14 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 16 Mar 2020 14:57:14 +0300
Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?=
 =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?=
In-Reply-To: <CAFHpkQFVaAQO8Hzp2BR5kySyyOrgNM11-Axt7WgfWb5soODKFw@mail.gmail.com>
References: <20200313080634.GI14751@sie.protva.ru>
 <5b7d2906a9e3deefdcb9eb0d3183f3a9.NginxMailingListRussian@forum.nginx.org>
 <CAFHpkQFVaAQO8Hzp2BR5kySyyOrgNM11-Axt7WgfWb5soODKFw@mail.gmail.com>
Message-ID: <20200316115714.GM12894@mdounin.ru>

Hello!

On Mon, Mar 16, 2020 at 12:54:33PM +0500, Илья Шипицин wrote:

> еще раз - "400 bad request" во многих случаях можно подсмотреть по
> error.log (на всякий случай запустите отладочную сборку nginx).
> если у вас будет 400, но в error.log тишина, то вы сузили количество
> возможных вариантов - можете поискать по исходному коду,
> такие места, где отдается 400 втихую есть, но их мало.

Если 400 вернул nginx, то в логе ошибок на уровне info должна быть 
причина, отладочная сборка не нужна.  Если вдруг известны 
ситуации, в которых это не происходит - об этом стоит сообщить, 
ибо это ошибка.

AFAIK, на текущий момент в поддерживаемых версиях подобных ошибок 
нет.  Последняя подобная ошибка была исправлена в nginx 1.13.6, в 
коде HTTP/2:

    *) Исправление: при использовании HTTP/2 nginx мог вернуть ошибку 400,
       не указав в логе причину.

В данном случае я бы скорее предположил, что 400 возвращает 
бекенд.  В отладочном логе, это, безусловно, будет явно видно, но 
можно обойтись и без отладочной сборки: просто залоггировать 
$upstream_status или вообще посмотреть tcpdump между nginx'ом и 
бекендом.

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

From nginx-forum на forum.nginx.org  Mon Mar 16 12:11:43 2020
From: nginx-forum на forum.nginx.org (Dmytro Lavryk)
Date: Mon, 16 Mar 2020 08:11:43 -0400
Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?=
 =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?=
In-Reply-To: <20200316115714.GM12894@mdounin.ru>
References: <20200316115714.GM12894@mdounin.ru>
Message-ID: <0b0f83b75e7c7384899d18a9bf423b65.NginxMailingListRussian@forum.nginx.org>

да, вы правы. Проверил - 400 отдает апстрим в данном случае.

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


From bgx на protva.ru  Mon Mar 16 12:14:10 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Mon, 16 Mar 2020 15:14:10 +0300
Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?=
 =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?=
In-Reply-To: <20200316115714.GM12894@mdounin.ru>
References: <20200313080634.GI14751@sie.protva.ru>
 <5b7d2906a9e3deefdcb9eb0d3183f3a9.NginxMailingListRussian@forum.nginx.org>
 <CAFHpkQFVaAQO8Hzp2BR5kySyyOrgNM11-Axt7WgfWb5soODKFw@mail.gmail.com>
 <20200316115714.GM12894@mdounin.ru>
Message-ID: <20200316121410.GD3939@protva.ru>

On Mon, Mar 16, 2020 at 02:57:14PM +0300, Maxim Dounin wrote:
> В данном случае я бы скорее предположил, что 400 возвращает 
> бекенд.  В отладочном логе, это, безусловно, будет явно видно, но 

 В данном случае товарищ посылает plain http на 443-й порт, который,
 несомненно, сконфигурён как ssl, потому что curl на него ходит по https
 и без проблем забирает указанный radio-stream. A nginx при запросе
 plain http на ssl-ном порту возвращает "400 Bad Request" таким же
 plain http. Проверено на первом попавшемся под руку nginx-e.
-- 
 Eugene Berdnikov

From mdounin на mdounin.ru  Mon Mar 16 14:57:48 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 16 Mar 2020 17:57:48 +0300
Subject: =?UTF-8?B?UmU6IEhUVFAvMS4xIDQwMCBCYWQgUmVxdWVzdCDQv9GA0Lgg0YDQtdGB0YLRgNC4?=
 =?UTF-8?B?0LzQtSDQsNGD0LTQuNC+INC/0L7RgtC+0LrQsA==?=
In-Reply-To: <20200316121410.GD3939@protva.ru>
References: <20200313080634.GI14751@sie.protva.ru>
 <5b7d2906a9e3deefdcb9eb0d3183f3a9.NginxMailingListRussian@forum.nginx.org>
 <CAFHpkQFVaAQO8Hzp2BR5kySyyOrgNM11-Axt7WgfWb5soODKFw@mail.gmail.com>
 <20200316115714.GM12894@mdounin.ru>
 <20200316121410.GD3939@protva.ru>
Message-ID: <20200316145748.GO12894@mdounin.ru>

Hello!

On Mon, Mar 16, 2020 at 03:14:10PM +0300, Evgeniy Berdnikov wrote:

> On Mon, Mar 16, 2020 at 02:57:14PM +0300, Maxim Dounin wrote:
> > В данном случае я бы скорее предположил, что 400 возвращает 
> > бекенд.  В отладочном логе, это, безусловно, будет явно видно, но 
> 
>  В данном случае товарищ посылает plain http на 443-й порт, который,
>  несомненно, сконфигурён как ssl, потому что curl на него ходит по https
>  и без проблем забирает указанный radio-stream. A nginx при запросе
>  plain http на ssl-ном порту возвращает "400 Bad Request" таким же
>  plain http. Проверено на первом попавшемся под руку nginx-e.

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

В тех немногих логах, что приводились, видно, что curl 
нормально получает ответ на GET, но получает 400 в ответ на HEAD.  
И вот это уже - явно проблема бекенда, что и подтвердил Dmytro 
Lavryk.

Моё письмо, впрочем, не про это, а про то, что если ошибку 
возвращает nginx - об этом явно будет в логе ошибок на уровне 
info, а если вдруг кто-то знает случаи, когда не будет - об этом 
стоит сообщить.

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

From gmm на csdoc.com  Thu Mar 19 20:03:36 2020
From: gmm на csdoc.com (Gena Makhomed)
Date: Thu, 19 Mar 2020 22:03:36 +0200
Subject: Keepalives considered harmful
Message-ID: <db65df1e-12a1-0511-040e-a84ab162adac@csdoc.com>

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

Интересная статья в блоге Cloudflare:

https://blog.cloudflare.com/keepalives-considered-harmful/

Keepalives considered harmful

-- 
Best regards,
  Gena


From nginx-forum на forum.nginx.org  Fri Mar 20 08:39:42 2020
From: nginx-forum на forum.nginx.org (inkognito0609)
Date: Fri, 20 Mar 2020 04:39:42 -0400
Subject: UDP Connection refused
In-Reply-To: <20200312123403.GH12894@mdounin.ru>
References: <20200312123403.GH12894@mdounin.ru>
Message-ID: <c71747501af2479e9eeb8837f9ebb955.NginxMailingListRussian@forum.nginx.org>

Спасибо за ссылку. Многое прояснило.
Да, проблема нашлась на стороне получателя.

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


From nginx-forum на forum.nginx.org  Fri Mar 20 09:00:36 2020
From: nginx-forum на forum.nginx.org (inkognito0609)
Date: Fri, 20 Mar 2020 05:00:36 -0400
Subject: 104: Connection reset by peer
Message-ID: <a44686d13e4cff1f3fd405c98823fd55.NginxMailingListRussian@forum.nginx.org>

nginx работает в качестве tcp lb
Периодически получаю 104: Connection reset by peer.
---
Если причинно следственная связь в системных вызовах?
writev() not ready (11: Resource temporarily unavailable)
recv() failed (104: Connection reset by peer)
или 104 ошибку получаем из-за того что не получили сообщений от сокета для
файлового дескриптора?
recv: fd:96 -1 of 16384
---
2020/03/20 04:54:21 [debug] 37456#0: *98446240 accept: 188.187.126.40:40513
fd:96
2020/03/20 04:54:21 [info] 37456#0: *98446240 client 188.187.126.40:40513
connected to 8.8.157.49:80
2020/03/20 04:54:21 [debug] 37456#0: *98446240 posix_memalign:
00005597192FA4F0:256 @16
2020/03/20 04:54:21 [debug] 37456#0: *98446240 generic phase: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 generic phase: 1
2020/03/20 04:54:21 [debug] 37456#0: *98446240 generic phase: 2
2020/03/20 04:54:21 [debug] 37456#0: *98446240 ssl preread handler
2020/03/20 04:54:21 [debug] 37456#0: *98446240 tcp_nodelay
2020/03/20 04:54:21 [debug] 37456#0: *98446240 proxy connection handler
2020/03/20 04:54:21 [debug] 37456#0: *98446240 malloc: 00005597192FA600:416
2020/03/20 04:54:21 [debug] 37456#0: *98446240 malloc:
000055971947AB00:16384
2020/03/20 04:54:21 [debug] 37456#0: *98446240 get rr peer, try: 8
2020/03/20 04:54:21 [debug] 37456#0: *98446240 get rr peer, current:
000055971928E448 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream socket 97
2020/03/20 04:54:21 [debug] 37456#0: *98446240 epoll add connection: fd:97
ev:80002005
2020/03/20 04:54:21 [debug] 37456#0: *98446240 connect to
10.121.15.75:31001, fd:97 #98446241
2020/03/20 04:54:21 [debug] 37456#0: *98446240 proxy connect: -2
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer add: 97:
1000:155123895
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer del: 97:
155123895
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream proxy connect
upstream
2020/03/20 04:54:21 [debug] 37456#0: *98446240 tcp_nodelay
2020/03/20 04:54:21 [info] 37456#0: *98446240 proxy 10.121.15.65:3564
connected to 10.121.15.75:31001
2020/03/20 04:54:21 [debug] 37456#0: *98446240 malloc:
000055971947EB10:16384
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream proxy add PROXY
protocol header
2020/03/20 04:54:21 [debug] 37456#0: *98446240 posix_memalign:
00005597192FA7B0:256 @16
2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0
0000000000000000, pos 00005597192FA820, size: 51 file: 0, size: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:0
s:51
2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev: 51 of 51
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter
0000000000000000
2020/03/20 04:54:21 [debug] 37456#0: *98446240 epoll add event: fd:96 op:1
ev:80002001
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer add: 96:
600000:155722896
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:0, avail:1
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:96 259 of 16384
2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0
0000000000000000, pos 000055971947AB00, size: 259 file: 0, size: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:1
s:259
2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev: 259 of 259
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter
0000000000000000
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old:
155722896, new: 155722896
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:0, avail:1
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:97 8388 of 16384
2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0
0000000000000000, pos 000055971947EB10, size: 8388 file: 0, size: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:1
s:8388
2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev: 8388 of 8388
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter
0000000000000000
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old:
155722896, new: 155722897
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old:
155722896, new: 155722897
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:0, avail:1
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:97 5592 of 16384
2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0
0000000000000000, pos 000055971947EB10, size: 5592 file: 0, size: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:1
s:5592
2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev: 5592 of 5592
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter
0000000000000000
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old:
155722896, new: 155722897
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old:
155722896, new: 155722897
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:0, avail:1
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:97 6990 of 16384
2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0
0000000000000000, pos 000055971947EB10, size: 6990 file: 0, size: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:1
s:6990
2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev: 6990 of 6990
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter
0000000000000000
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old:
155722896, new: 155722897
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old:
155722896, new: 155722897
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:0, avail:1
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:97 6990 of 16384
2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0
0000000000000000, pos 000055971947EB10, size: 6990 file: 0, size: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:1
s:6990
2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev: 6990 of 6990
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter
0000000000000000
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old:
155722896, new: 155722897
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old:
155722896, new: 155722897
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:0, avail:1
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:97 5592 of 16384
2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0
0000000000000000, pos 000055971947EB10, size: 5592 file: 0, size: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:1
s:5592
2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev: 4160 of 5592
2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev: -1 of 1432
2020/03/20 04:54:21 [debug] 37456#0: *98446240 writev() not ready (11:
Resource temporarily unavailable)
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter
00005597192FA890
2020/03/20 04:54:21 [debug] 37456#0: *98446240 epoll add event: fd:96 op:3
ev:80002005
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old:
155722896, new: 155722898
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old:
155722896, new: 155722898
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:0, avail:1
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:97 9786 of 10792
2020/03/20 04:54:21 [debug] 37456#0: *98446240 posix_memalign:
0000559719349B70:256 @16
2020/03/20 04:54:21 [debug] 37456#0: *98446240 write old buf t:1 f:0
0000000000000000, pos 000055971947FB50, size: 1432 file: 0, size: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0
0000000000000000, pos 00005597194800E8, size: 9786 file: 0, size: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:1
s:11218
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter
00005597192FA890
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old:
155722896, new: 155722898
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old:
155722896, new: 155722898
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:0, avail:1
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:97 1006 of 1006
2020/03/20 04:54:21 [debug] 37456#0: *98446240 write old buf t:1 f:0
0000000000000000, pos 000055971947FB50, size: 1432 file: 0, size: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 write old buf t:1 f:0
0000000000000000, pos 00005597194800E8, size: 9786 file: 0, size: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:1 f:0
0000000000000000, pos 0000559719482722, size: 1006 file: 0, size: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:0 f:1
s:12224
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter
00005597192FA890
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old:
155722896, new: 155722898
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old:
155722896, new: 155722898
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old:
155722896, new: 155722898
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer: 96, old:
155722896, new: 155722898
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: eof:1, avail:1
2020/03/20 04:54:21 [debug] 37456#0: *98446240 recv: fd:96 -1 of 16384
2020/03/20 04:54:21 [info] 37456#0: *98446240 recv() failed (104: Connection
reset by peer) while proxying and reading from client, client:
188.187.126.40, server: 8.8.157.49:80, upstream: "10.121.15.75:31001", bytes
from/to client:259/32120, bytes from/to upstream:44344/310
2020/03/20 04:54:21 [debug] 37456#0: *98446240 posix_memalign:
0000559719349C80:256 @16
2020/03/20 04:54:21 [debug] 37456#0: *98446240 write new buf t:0 f:0
0000000000000000, pos 000055971947AB00, size: 0 file: 0, size: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream write filter: l:1 f:1
s:0
2020/03/20 04:54:21 [info] 37456#0: *98446240 client disconnected, bytes
from/to client:259/32120, bytes from/to upstream:44344/310
2020/03/20 04:54:21 [debug] 37456#0: *98446240 finalize stream proxy: 200
2020/03/20 04:54:21 [debug] 37456#0: *98446240 free rr peer 8 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 close stream proxy upstream
connection: 97
2020/03/20 04:54:21 [debug] 37456#0: *98446240 reusable connection: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 finalize stream session: 200
2020/03/20 04:54:21 [debug] 37456#0: *98446240 stream log handler
2020/03/20 04:54:21 [debug] 37456#0: *98446240 close stream connection: 96
2020/03/20 04:54:21 [debug] 37456#0: *98446240 event timer del: 96:
155722896
2020/03/20 04:54:21 [debug] 37456#0: *98446240 reusable connection: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 000055971947EB10
2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 000055971947AB00
2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 00005597192FA600
2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 0000559719352190,
unused: 8
2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 00005597193522A0,
unused: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 00005597192FA4F0,
unused: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 00005597192FA7B0,
unused: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 0000559719349B70,
unused: 0
2020/03/20 04:54:21 [debug] 37456#0: *98446240 free: 0000559719349C80,
unused: 128
---
буду благодарен за объяснение для слабых.

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


From chipitsine на gmail.com  Fri Mar 20 10:11:40 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 20 Mar 2020 15:11:40 +0500
Subject: Keepalives considered harmful
In-Reply-To: <db65df1e-12a1-0511-040e-a84ab162adac@csdoc.com>
References: <db65df1e-12a1-0511-040e-a84ab162adac@csdoc.com>
Message-ID: <CAFHpkQG=B5gopQVfhuy84ohHb4H0VO+Ld2h7AzJY5cAu4yrk9Q@mail.gmail.com>

Речь идёт про то, что не все воркеры одинаково хороши. Но не раскрывается,
почему они могут быть нехороши. Блокирущие воркеры?

On Fri, Mar 20, 2020, 1:03 AM Gena Makhomed <gmm на csdoc.com> wrote:

> Здравствуйте, All!
>
> Интересная статья в блоге Cloudflare:
>
> https://blog.cloudflare.com/keepalives-considered-harmful/
>
> Keepalives considered harmful
>
> --
> 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/20200320/775c8f81/attachment.htm>

From bgx на protva.ru  Fri Mar 20 10:36:02 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Fri, 20 Mar 2020 13:36:02 +0300
Subject: 104: Connection reset by peer
In-Reply-To: <a44686d13e4cff1f3fd405c98823fd55.NginxMailingListRussian@forum.nginx.org>
References: <a44686d13e4cff1f3fd405c98823fd55.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200320103602.GB13008@protva.ru>

On Fri, Mar 20, 2020 at 05:00:36AM -0400, inkognito0609 wrote:
> nginx работает в качестве tcp lb
> Периодически получаю 104: Connection reset by peer.
> ---
> Если причинно следственная связь в системных вызовах?
> writev() not ready (11: Resource temporarily unavailable)
> recv() failed (104: Connection reset by peer)
> или 104 ошибку получаем из-за того что не получили сообщений от сокета для
> файлового дескриптора?

 ECONNRESET означает, что по сети прилетел RST, что и написано текстом.
 Никакой связи с EAGAIN у него нет.
-- 
 Eugene Berdnikov

From valery+nginxru на grid.net.ru  Fri Mar 20 11:04:58 2020
From: valery+nginxru на grid.net.ru (Valery Kholodkov)
Date: Fri, 20 Mar 2020 12:04:58 +0100
Subject: Keepalives considered harmful
In-Reply-To: <CAFHpkQG=B5gopQVfhuy84ohHb4H0VO+Ld2h7AzJY5cAu4yrk9Q@mail.gmail.com>
References: <db65df1e-12a1-0511-040e-a84ab162adac@csdoc.com>
 <CAFHpkQG=B5gopQVfhuy84ohHb4H0VO+Ld2h7AzJY5cAu4yrk9Q@mail.gmail.com>
Message-ID: <a1099762-b582-198d-e670-7e70bf36689f@grid.net.ru>

Там возникает дисбаланс в загрузке воркеров из-за того что часть 
клиентов привязаны к своим воркерам через keep-alive. Отключая 
keep-alive они заставляют клиентов мигрировать на менее загруженные воркеры.

Описывается комуникация внутри их стэка, про что и статья. Полагаю, 
заголовок, нужно читать "[In some cases] keepalives considered harmful".

On 20-03-20 11:11, Илья Шипицин wrote:
> Речь идёт про то, что не все воркеры одинаково хороши. Но не 
> раскрывается, почему они могут быть нехороши. Блокирущие воркеры?
> 
> On Fri, Mar 20, 2020, 1:03 AM Gena Makhomed <gmm на csdoc.com 
> <mailto:gmm на csdoc.com>> wrote:
> 
>     Здравствуйте, All!
> 
>     Интересная статья в блоге Cloudflare:
> 
>     https://blog.cloudflare.com/keepalives-considered-harmful/
> 
>     Keepalives considered harmful
-- 
Val

From nginx-forum на forum.nginx.org  Fri Mar 20 11:17:44 2020
From: nginx-forum на forum.nginx.org (inkognito0609)
Date: Fri, 20 Mar 2020 07:17:44 -0400
Subject: 104: Connection reset by peer
In-Reply-To: <20200320103602.GB13008@protva.ru>
References: <20200320103602.GB13008@protva.ru>
Message-ID: <46111aa7d8e21dda378d47533fb4c5d7.NginxMailingListRussian@forum.nginx.org>

Странно, потому что tcpdump показывает что RST отправляет именно балансер
---
11:02:29.208274 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [S], seq
1825789029, win 29200, options [mss 1460,sackOK,TS val 4257877938 ecr
0,nop,wscale 9], length 0
11:02:29.208683 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [S.], seq
2625988586, ack 1825789030, win 27960, options [mss 1410,sackOK,TS val
1022466629 ecr 4257877938,nop,wscale 9], length 0
11:02:29.208696 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 1, win
58, options [nop,nop,TS val 4257877939 ecr 1022466629], length 0
11:02:29.208713 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [P.], seq 1:50,
ack 1, win 58, options [nop,nop,TS val 4257877939 ecr 1022466629], length
49
11:02:29.208904 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [P.], seq
50:309, ack 1, win 58, options [nop,nop,TS val 4257877939 ecr 1022466629],
length 259
11:02:29.209045 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], ack 50,
win 55, options [nop,nop,TS val 1022466630 ecr 4257877939], length 0
11:02:29.209183 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], ack 309,
win 57, options [nop,nop,TS val 1022466630 ecr 4257877939], length 0
11:02:29.209639 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq
1:2797, ack 309, win 57, options [nop,nop,TS val 1022466630 ecr 4257877939],
length 2796
11:02:29.209642 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 2797,
win 68, options [nop,nop,TS val 4257877940 ecr 1022466630], length 0
11:02:29.209720 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq
2797:6991, ack 309, win 57, options [nop,nop,TS val 1022466630 ecr
4257877939], length 4194
11:02:29.209731 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 6991,
win 85, options [nop,nop,TS val 4257877940 ecr 1022466630], length 0
11:02:29.209817 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq
6991:11185, ack 309, win 57, options [nop,nop,TS val 1022466630 ecr
4257877939], length 4194
11:02:29.209822 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 11185,
win 101, options [nop,nop,TS val 4257877940 ecr 1022466630], length 0
11:02:29.209915 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq
11185:12583, ack 309, win 57, options [nop,nop,TS val 1022466630 ecr
4257877939], length 1398
11:02:29.209920 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 12583,
win 107, options [nop,nop,TS val 4257877940 ecr 1022466630], length 0
11:02:29.209967 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq
12583:13981, ack 309, win 57, options [nop,nop,TS val 1022466630 ecr
4257877939], length 1398
11:02:29.209973 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 13981,
win 112, options [nop,nop,TS val 4257877940 ecr 1022466630], length 0
11:02:29.210103 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq
13981:20971, ack 309, win 57, options [nop,nop,TS val 1022466630 ecr
4257877940], length 6990
11:02:29.210110 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 20971,
win 140, options [nop,nop,TS val 4257877940 ecr 1022466630], length 0
11:02:29.210147 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq
20971:25165, ack 309, win 57, options [nop,nop,TS val 1022466630 ecr
4257877940], length 4194
11:02:29.210153 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 25165,
win 156, options [nop,nop,TS val 4257877940 ecr 1022466630], length 0
11:02:29.210184 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [P.], seq
25165:27961, ack 309, win 57, options [nop,nop,TS val 1022466630 ecr
4257877940], length 2796
11:02:29.210189 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 27961,
win 167, options [nop,nop,TS val 4257877940 ecr 1022466630], length 0
11:02:29.210211 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq
27961:36349, ack 309, win 57, options [nop,nop,TS val 1022466631 ecr
4257877940], length 8388
11:02:29.210216 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 36349,
win 200, options [nop,nop,TS val 4257877940 ecr 1022466631], length 0
11:02:29.210399 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq
36349:37747, ack 309, win 57, options [nop,nop,TS val 1022466631 ecr
4257877940], length 1398
11:02:29.210406 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 37747,
win 205, options [nop,nop,TS val 4257877940 ecr 1022466631], length 0
11:02:29.210431 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [.], seq
37747:48931, ack 309, win 57, options [nop,nop,TS val 1022466631 ecr
4257877940], length 11184
11:02:29.210436 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 48931,
win 249, options [nop,nop,TS val 4257877940 ecr 1022466631], length 0
11:02:29.210508 IP 10.121.15.74.31001 > lb1.cc1.46376: Flags [FP.], seq
48931:50629, ack 309, win 57, options [nop,nop,TS val 1022466631 ecr
4257877940], length 1698
11:02:29.210528 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 50630,
win 255, options [nop,nop,TS val 4257877940 ecr 1022466631], length 0
11:02:29.215540 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [R.], seq 309,
ack 50630, win 255, options [nop,nop,TS val 4257877945 ecr 1022466631],
length 0

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


From chipitsine на gmail.com  Fri Mar 20 11:36:42 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 20 Mar 2020 16:36:42 +0500
Subject: Keepalives considered harmful
In-Reply-To: <a1099762-b582-198d-e670-7e70bf36689f@grid.net.ru>
References: <db65df1e-12a1-0511-040e-a84ab162adac@csdoc.com>
 <CAFHpkQG=B5gopQVfhuy84ohHb4H0VO+Ld2h7AzJY5cAu4yrk9Q@mail.gmail.com>
 <a1099762-b582-198d-e670-7e70bf36689f@grid.net.ru>
Message-ID: <CAFHpkQFvhBcz1cbb_W11Cr-RJuD7k1kHZ97hpSdGW+jOusyepA@mail.gmail.com>

пт, 20 мар. 2020 г. в 16:05, Valery Kholodkov <valery+nginxru на grid.net.ru>:

> Там возникает дисбаланс в загрузке воркеров из-за того что часть
> клиентов привязаны к своим воркерам через keep-alive. Отключая
> keep-alive они заставляют клиентов мигрировать на менее загруженные
> воркеры.
>

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

надо еще раз перечитать ))


>
> Описывается комуникация внутри их стэка, про что и статья. Полагаю,
> заголовок, нужно читать "[In some cases] keepalives considered harmful".
>
> On 20-03-20 11:11, Илья Шипицин wrote:
> > Речь идёт про то, что не все воркеры одинаково хороши. Но не
> > раскрывается, почему они могут быть нехороши. Блокирущие воркеры?
> >
> > On Fri, Mar 20, 2020, 1:03 AM Gena Makhomed <gmm на csdoc.com
> > <mailto:gmm на csdoc.com>> wrote:
> >
> >     Здравствуйте, All!
> >
> >     Интересная статья в блоге Cloudflare:
> >
> >     https://blog.cloudflare.com/keepalives-considered-harmful/
> >
> >     Keepalives considered harmful
> --
> Val
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200320/08495572/attachment.htm>

From bgx на protva.ru  Fri Mar 20 13:24:43 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Fri, 20 Mar 2020 16:24:43 +0300
Subject: 104: Connection reset by peer
In-Reply-To: <46111aa7d8e21dda378d47533fb4c5d7.NginxMailingListRussian@forum.nginx.org>
References: <20200320103602.GB13008@protva.ru>
 <46111aa7d8e21dda378d47533fb4c5d7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200320132443.GE14751@sie.protva.ru>

On Fri, Mar 20, 2020 at 07:17:44AM -0400, inkognito0609 wrote:
> Странно, потому что tcpdump показывает что RST отправляет именно балансер

 Значит, это не тот RST, а случайно попавшийся на глаза в дампе.
 Неудивительно, что он оказался не от того процесса, который нужен.

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

> 11:02:29.210528 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [.], ack 50630,
> win 255, options [nop,nop,TS val 4257877940 ecr 1022466631], length 0
> 11:02:29.215540 IP lb1.cc1.46376 > 10.121.15.74.31001: Flags [R.], seq 309,
> ack 50630, win 255, options [nop,nop,TS val 4257877945 ecr 1022466631],
> length 0
-- 
 Eugene Berdnikov

From nginx-forum на forum.nginx.org  Mon Mar 23 09:01:12 2020
From: nginx-forum на forum.nginx.org (opan)
Date: Mon, 23 Mar 2020 05:01:12 -0400
Subject: =?UTF-8?B?0KLQsNC50LzQsNGD0YLRiyBwcm94eSBwYXNz?=
Message-ID: <95b6d3a414d210df80592d01a2fd1d5d.NginxMailingListRussian@forum.nginx.org>

У нас есть одна площадка, нжинкс принимает запросы и проксирует на бэкенд
через fcgi_pass. В логах нжинса мы видим upstream_response_time 40мс. 
Появилась вторая площадка, мы принимаем там трафик и отправляем все на
первую площадку через proxy_pass. Так же логируем здесь
upstream_reponse_time и наблюдаем очень большие значения. Мы ожидали, что
добавится просто летенси между новой и старой площадкой, плюс какие-то
небольшие накладные расходы nginx. Но это не так, в upstream_response_time
мы видим 130-150мс ( в 3.5 раз больше, чем на площадке 1). При этом, если
замерять время запросов от клиента, то total_time курла примерно одинаков
для обоих площадок. Как такое может быть? Почему в логах
upstream_reponse_time больше в 3-4 раза, а время ответа при этом практически
не меняется?

Вот фрагмент конфигурации, в которой проксируем:

 location = /ххх {
   
        proxy_cache off;
        proxy_redirect off;
        proxy_pass_request_body on;
        proxy_pass_request_headers on;
        proxy_next_upstream off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass https://second.domain/xxx;
        proxy_http_version 1.1;
        proxy_set_header Connection "";

        }

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


From chipitsine на gmail.com  Mon Mar 23 11:35:46 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 23 Mar 2020 16:35:46 +0500
Subject: =?UTF-8?B?UmU6INCi0LDQudC80LDRg9GC0YsgcHJveHkgcGFzcw==?=
In-Reply-To: <95b6d3a414d210df80592d01a2fd1d5d.NginxMailingListRussian@forum.nginx.org>
References: <95b6d3a414d210df80592d01a2fd1d5d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQEn2cEf=4Y-87m1_r0R=hL4N+RwJUNXQ2g3jSn6WQgF=Q@mail.gmail.com>

пара моментов

1) у вас proxy_pass на https, по крайней мере первоначальный хендшейк может
быть долгим (например, если клиент захочет сделать OCSP проверку). выглядит
так, как будто у вас
должен быть кипэлайв до бекенда, поэтому это соображение должно касаться
только редких запросов

2) возможно, у вас работает буферизация запросов-ответов. попробуйте
"proxy_buffering off;" и "proxy_request_buffering off;" ?

пн, 23 мар. 2020 г. в 14:01, opan <nginx-forum на forum.nginx.org>:

> У нас есть одна площадка, нжинкс принимает запросы и проксирует на бэкенд
> через fcgi_pass. В логах нжинса мы видим upstream_response_time 40мс.
> Появилась вторая площадка, мы принимаем там трафик и отправляем все на
> первую площадку через proxy_pass. Так же логируем здесь
> upstream_reponse_time и наблюдаем очень большие значения. Мы ожидали, что
> добавится просто летенси между новой и старой площадкой, плюс какие-то
> небольшие накладные расходы nginx. Но это не так, в upstream_response_time
> мы видим 130-150мс ( в 3.5 раз больше, чем на площадке 1). При этом, если
> замерять время запросов от клиента, то total_time курла примерно одинаков
> для обоих площадок. Как такое может быть? Почему в логах
> upstream_reponse_time больше в 3-4 раза, а время ответа при этом
> практически
> не меняется?
>
> Вот фрагмент конфигурации, в которой проксируем:
>
>  location = /ххх {
>
>         proxy_cache off;
>         proxy_redirect off;
>         proxy_pass_request_body on;
>         proxy_pass_request_headers on;
>         proxy_next_upstream off;
>         proxy_set_header Host $host;
>         proxy_set_header X-Real-IP $remote_addr;
>         proxy_pass https://second.domain/xxx;
>         proxy_http_version 1.1;
>         proxy_set_header Connection "";
>
>         }
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,287422,287422#msg-287422
>
> _______________________________________________
> 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/20200323/7a5101b0/attachment.htm>

From nginx-forum на forum.nginx.org  Mon Mar 23 12:57:12 2020
From: nginx-forum на forum.nginx.org (opan)
Date: Mon, 23 Mar 2020 08:57:12 -0400
Subject: =?UTF-8?B?UmU6INCi0LDQudC80LDRg9GC0YsgcHJveHkgcGFzcw==?=
In-Reply-To: <CAFHpkQEn2cEf=4Y-87m1_r0R=hL4N+RwJUNXQ2g3jSn6WQgF=Q@mail.gmail.com>
References: <CAFHpkQEn2cEf=4Y-87m1_r0R=hL4N+RwJUNXQ2g3jSn6WQgF=Q@mail.gmail.com>
Message-ID: <631231b8afc7a4b6e4198952506ca8ed.NginxMailingListRussian@forum.nginx.org>

1. Про ssl верно, мы замеряли сколько времени занимает установка соединения.
Это 20-30мс, не больше.
2. Пробовали, не помогает 

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

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


From chipitsine на gmail.com  Tue Mar 24 08:50:17 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 24 Mar 2020 13:50:17 +0500
Subject: duplicate Host header
Message-ID: <CAFHpkQGWfT6n9ufW4hBSHm1m+Tv9GH0BTJQ7AYi99tzMNJQLbw@mail.gmail.com>

привет,

вижу 400-ки на вот такое

2020/03/24 09:43:55 [info] 22318#22318: *514553220 client sent duplicate
host header: "Host: example.ru <http://diadoc-api.kontur.ru/>", previous
value: "Host: example.ru" while reading client request headers, client:
X.X.X.X


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

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

From mdounin на mdounin.ru  Tue Mar 24 12:51:09 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 24 Mar 2020 15:51:09 +0300
Subject: duplicate Host header
In-Reply-To: <CAFHpkQGWfT6n9ufW4hBSHm1m+Tv9GH0BTJQ7AYi99tzMNJQLbw@mail.gmail.com>
References: <CAFHpkQGWfT6n9ufW4hBSHm1m+Tv9GH0BTJQ7AYi99tzMNJQLbw@mail.gmail.com>
Message-ID: <20200324125109.GD1578@mdounin.ru>

Hello!

On Tue, Mar 24, 2020 at 01:50:17PM +0500, Илья Шипицин wrote:

> вижу 400-ки на вот такое
> 
> 2020/03/24 09:43:55 [info] 22318#22318: *514553220 client sent duplicate
> host header: "Host: example.ru <http://diadoc-api.kontur.ru/>", previous
> value: "Host: example.ru" while reading client request headers, client:
> X.X.X.X
> 
> 
> хост в обоих случаях одинаковый.
> понятно, что, наверное, RFC тут не ночевало. с другой стороны, ну послал
> клиент два раза одинаковый хост. никто ж не умер. может пропускать такие
> запросы ? или есть какой-то риск ?

Есть какой-то риск, даже если хосты строго одинаковые.  Например 
такой, что "два раза одинаковый хост" - это по RFC то же самое, 
что "Host: example.ru, example.ru", что совсем не то же самое, что 
"Host: example.ru".

Ну и до кучи, отклонять такие запросы - прямое требованием RFC 7230:

   A server MUST respond with a 400 (Bad Request) status code to any
   HTTP/1.1 request message that lacks a Host header field and to any
   request message that contains more than one Host header field or a
   Host header field with an invalid field-value.

Если очень хочется, чтобы "может пропускать", то так было с nginx 
0.7.0 и до nginx 1.17.8 включительно.  Начиная с nginx 1.17.9 
такие запросы отклоняются.  Если есть какие-то самописные клиенты, 
которые нарушают RFC и шлют несколько заголовков Host - нужно 
исправить этих клиентов.

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

From chipitsine на gmail.com  Tue Mar 24 13:27:57 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 24 Mar 2020 18:27:57 +0500
Subject: duplicate Host header
In-Reply-To: <20200324125109.GD1578@mdounin.ru>
References: <CAFHpkQGWfT6n9ufW4hBSHm1m+Tv9GH0BTJQ7AYi99tzMNJQLbw@mail.gmail.com>
 <20200324125109.GD1578@mdounin.ru>
Message-ID: <CAFHpkQH_DTRfDM=rhEQ5H3P6hYCQc_d8jaK7jyRRJqkZ1uOK7A@mail.gmail.com>

вт, 24 мар. 2020 г. в 17:51, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Tue, Mar 24, 2020 at 01:50:17PM +0500, Илья Шипицин wrote:
>
> > вижу 400-ки на вот такое
> >
> > 2020/03/24 09:43:55 [info] 22318#22318: *514553220 client sent duplicate
> > host header: "Host: example.ru <http://diadoc-api.kontur.ru/>", previous
> > value: "Host: example.ru" while reading client request headers, client:
> > X.X.X.X
> >
> >
> > хост в обоих случаях одинаковый.
> > понятно, что, наверное, RFC тут не ночевало. с другой стороны, ну послал
> > клиент два раза одинаковый хост. никто ж не умер. может пропускать такие
> > запросы ? или есть какой-то риск ?
>
> Есть какой-то риск, даже если хосты строго одинаковые.  Например
> такой, что "два раза одинаковый хост" - это по RFC то же самое,
> что "Host: example.ru, example.ru", что совсем не то же самое, что
> "Host: example.ru".
>
> Ну и до кучи, отклонять такие запросы - прямое требованием RFC 7230:
>
>    A server MUST respond with a 400 (Bad Request) status code to any
>    HTTP/1.1 request message that lacks a Host header field and to any
>    request message that contains more than one Host header field or a
>    Host header field with an invalid field-value.
>
> Если очень хочется, чтобы "может пропускать", то так было с nginx
> 0.7.0 и до nginx 1.17.8 включительно.  Начиная с nginx 1.17.9
> такие запросы отклоняются.  Если есть какие-то самописные клиенты,
> которые нарушают RFC и шлют несколько заголовков Host - нужно
> исправить этих клиентов.
>

а можно настройку сделать, чтобы можно было вернуть "как было раньше" ?

клиентов править, наверное, надо, но это не наша война.


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

From mdounin на mdounin.ru  Tue Mar 24 13:50:01 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 24 Mar 2020 16:50:01 +0300
Subject: duplicate Host header
In-Reply-To: <CAFHpkQH_DTRfDM=rhEQ5H3P6hYCQc_d8jaK7jyRRJqkZ1uOK7A@mail.gmail.com>
References: <CAFHpkQGWfT6n9ufW4hBSHm1m+Tv9GH0BTJQ7AYi99tzMNJQLbw@mail.gmail.com>
 <20200324125109.GD1578@mdounin.ru>
 <CAFHpkQH_DTRfDM=rhEQ5H3P6hYCQc_d8jaK7jyRRJqkZ1uOK7A@mail.gmail.com>
Message-ID: <20200324135001.GE1578@mdounin.ru>

Hello!

On Tue, Mar 24, 2020 at 06:27:57PM +0500, Илья Шипицин wrote:

> вт, 24 мар. 2020 г. в 17:51, Maxim Dounin <mdounin на mdounin.ru>:
> 
> > Hello!
> >
> > On Tue, Mar 24, 2020 at 01:50:17PM +0500, Илья Шипицин wrote:
> >
> > > вижу 400-ки на вот такое
> > >
> > > 2020/03/24 09:43:55 [info] 22318#22318: *514553220 client sent duplicate
> > > host header: "Host: example.ru <http://diadoc-api.kontur.ru/>", previous
> > > value: "Host: example.ru" while reading client request headers, client:
> > > X.X.X.X
> > >
> > >
> > > хост в обоих случаях одинаковый.
> > > понятно, что, наверное, RFC тут не ночевало. с другой стороны, ну послал
> > > клиент два раза одинаковый хост. никто ж не умер. может пропускать такие
> > > запросы ? или есть какой-то риск ?
> >
> > Есть какой-то риск, даже если хосты строго одинаковые.  Например
> > такой, что "два раза одинаковый хост" - это по RFC то же самое,
> > что "Host: example.ru, example.ru", что совсем не то же самое, что
> > "Host: example.ru".
> >
> > Ну и до кучи, отклонять такие запросы - прямое требованием RFC 7230:
> >
> >    A server MUST respond with a 400 (Bad Request) status code to any
> >    HTTP/1.1 request message that lacks a Host header field and to any
> >    request message that contains more than one Host header field or a
> >    Host header field with an invalid field-value.
> >
> > Если очень хочется, чтобы "может пропускать", то так было с nginx
> > 0.7.0 и до nginx 1.17.8 включительно.  Начиная с nginx 1.17.9
> > такие запросы отклоняются.  Если есть какие-то самописные клиенты,
> > которые нарушают RFC и шлют несколько заголовков Host - нужно
> > исправить этих клиентов.
> >
> 
> а можно настройку сделать, чтобы можно было вернуть "как было раньше" ?

Нет.

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

From chipitsine на gmail.com  Tue Mar 24 13:56:43 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 24 Mar 2020 18:56:43 +0500
Subject: duplicate Host header
In-Reply-To: <20200324135001.GE1578@mdounin.ru>
References: <CAFHpkQGWfT6n9ufW4hBSHm1m+Tv9GH0BTJQ7AYi99tzMNJQLbw@mail.gmail.com>
 <20200324125109.GD1578@mdounin.ru>
 <CAFHpkQH_DTRfDM=rhEQ5H3P6hYCQc_d8jaK7jyRRJqkZ1uOK7A@mail.gmail.com>
 <20200324135001.GE1578@mdounin.ru>
Message-ID: <CAFHpkQFe5RR07Dq7yM3YTmz9eRbYDYCr+Dr=4M_SupY9eEGAKg@mail.gmail.com>

так а как мы бы узнали, что у нас такое есть. никакого режима "dry run"

вт, 24 мар. 2020 г. в 18:51, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Tue, Mar 24, 2020 at 06:27:57PM +0500, Илья Шипицин wrote:
>
> > вт, 24 мар. 2020 г. в 17:51, Maxim Dounin <mdounin на mdounin.ru>:
> >
> > > Hello!
> > >
> > > On Tue, Mar 24, 2020 at 01:50:17PM +0500, Илья Шипицин wrote:
> > >
> > > > вижу 400-ки на вот такое
> > > >
> > > > 2020/03/24 09:43:55 [info] 22318#22318: *514553220 client sent
> duplicate
> > > > host header: "Host: example.ru <http://diadoc-api.kontur.ru/>",
> previous
> > > > value: "Host: example.ru" while reading client request headers,
> client:
> > > > X.X.X.X
> > > >
> > > >
> > > > хост в обоих случаях одинаковый.
> > > > понятно, что, наверное, RFC тут не ночевало. с другой стороны, ну
> послал
> > > > клиент два раза одинаковый хост. никто ж не умер. может пропускать
> такие
> > > > запросы ? или есть какой-то риск ?
> > >
> > > Есть какой-то риск, даже если хосты строго одинаковые.  Например
> > > такой, что "два раза одинаковый хост" - это по RFC то же самое,
> > > что "Host: example.ru, example.ru", что совсем не то же самое, что
> > > "Host: example.ru".
> > >
> > > Ну и до кучи, отклонять такие запросы - прямое требованием RFC 7230:
> > >
> > >    A server MUST respond with a 400 (Bad Request) status code to any
> > >    HTTP/1.1 request message that lacks a Host header field and to any
> > >    request message that contains more than one Host header field or a
> > >    Host header field with an invalid field-value.
> > >
> > > Если очень хочется, чтобы "может пропускать", то так было с nginx
> > > 0.7.0 и до nginx 1.17.8 включительно.  Начиная с nginx 1.17.9
> > > такие запросы отклоняются.  Если есть какие-то самописные клиенты,
> > > которые нарушают RFC и шлют несколько заголовков Host - нужно
> > > исправить этих клиентов.
> > >
> >
> > а можно настройку сделать, чтобы можно было вернуть "как было раньше" ?
>
> Нет.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200324/dd7c00a2/attachment-0001.htm>

From chipitsine на gmail.com  Tue Mar 24 16:29:28 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 24 Mar 2020 21:29:28 +0500
Subject: duplicate Host header
In-Reply-To: <CAFHpkQFe5RR07Dq7yM3YTmz9eRbYDYCr+Dr=4M_SupY9eEGAKg@mail.gmail.com>
References: <CAFHpkQGWfT6n9ufW4hBSHm1m+Tv9GH0BTJQ7AYi99tzMNJQLbw@mail.gmail.com>
 <20200324125109.GD1578@mdounin.ru>
 <CAFHpkQH_DTRfDM=rhEQ5H3P6hYCQc_d8jaK7jyRRJqkZ1uOK7A@mail.gmail.com>
 <20200324135001.GE1578@mdounin.ru>
 <CAFHpkQFe5RR07Dq7yM3YTmz9eRbYDYCr+Dr=4M_SupY9eEGAKg@mail.gmail.com>
Message-ID: <CAFHpkQGm=ViazYmU1yYG0u-xLCudxJ1k2_r2O5uXTeCUOB73nA@mail.gmail.com>

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

живешь, живешь, думаешь, что у тебя все ок.
потом обновляешься до 1.17.9, и по логам идут 400-ки.

смотришь в error.log - там duplicate Host header (про который ты ранее и
знать не знал, и без понятия, в чем там вообще прблема, потому что ее нет
никакой)

какая-то абстрактная задача запретить такие хедера, задача ради самой задачи

вт, 24 мар. 2020 г. в 18:56, Илья Шипицин <chipitsine на gmail.com>:

> так а как мы бы узнали, что у нас такое есть. никакого режима "dry run"
>
> вт, 24 мар. 2020 г. в 18:51, Maxim Dounin <mdounin на mdounin.ru>:
>
>> Hello!
>>
>> On Tue, Mar 24, 2020 at 06:27:57PM +0500, Илья Шипицин wrote:
>>
>> > вт, 24 мар. 2020 г. в 17:51, Maxim Dounin <mdounin на mdounin.ru>:
>> >
>> > > Hello!
>> > >
>> > > On Tue, Mar 24, 2020 at 01:50:17PM +0500, Илья Шипицин wrote:
>> > >
>> > > > вижу 400-ки на вот такое
>> > > >
>> > > > 2020/03/24 09:43:55 [info] 22318#22318: *514553220 client sent
>> duplicate
>> > > > host header: "Host: example.ru <http://diadoc-api.kontur.ru/>",
>> previous
>> > > > value: "Host: example.ru" while reading client request headers,
>> client:
>> > > > X.X.X.X
>> > > >
>> > > >
>> > > > хост в обоих случаях одинаковый.
>> > > > понятно, что, наверное, RFC тут не ночевало. с другой стороны, ну
>> послал
>> > > > клиент два раза одинаковый хост. никто ж не умер. может пропускать
>> такие
>> > > > запросы ? или есть какой-то риск ?
>> > >
>> > > Есть какой-то риск, даже если хосты строго одинаковые.  Например
>> > > такой, что "два раза одинаковый хост" - это по RFC то же самое,
>> > > что "Host: example.ru, example.ru", что совсем не то же самое, что
>> > > "Host: example.ru".
>> > >
>> > > Ну и до кучи, отклонять такие запросы - прямое требованием RFC 7230:
>> > >
>> > >    A server MUST respond with a 400 (Bad Request) status code to any
>> > >    HTTP/1.1 request message that lacks a Host header field and to any
>> > >    request message that contains more than one Host header field or a
>> > >    Host header field with an invalid field-value.
>> > >
>> > > Если очень хочется, чтобы "может пропускать", то так было с nginx
>> > > 0.7.0 и до nginx 1.17.8 включительно.  Начиная с nginx 1.17.9
>> > > такие запросы отклоняются.  Если есть какие-то самописные клиенты,
>> > > которые нарушают RFC и шлют несколько заголовков Host - нужно
>> > > исправить этих клиентов.
>> > >
>> >
>> > а можно настройку сделать, чтобы можно было вернуть "как было раньше" ?
>>
>> Нет.
>>
>> --
>> Maxim Dounin
>> http://mdounin.ru/
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200324/f74227c6/attachment.htm>

From mdounin на mdounin.ru  Wed Mar 25 13:21:44 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 25 Mar 2020 16:21:44 +0300
Subject: duplicate Host header
In-Reply-To: <CAFHpkQGm=ViazYmU1yYG0u-xLCudxJ1k2_r2O5uXTeCUOB73nA@mail.gmail.com>
References: <CAFHpkQGWfT6n9ufW4hBSHm1m+Tv9GH0BTJQ7AYi99tzMNJQLbw@mail.gmail.com>
 <20200324125109.GD1578@mdounin.ru>
 <CAFHpkQH_DTRfDM=rhEQ5H3P6hYCQc_d8jaK7jyRRJqkZ1uOK7A@mail.gmail.com>
 <20200324135001.GE1578@mdounin.ru>
 <CAFHpkQFe5RR07Dq7yM3YTmz9eRbYDYCr+Dr=4M_SupY9eEGAKg@mail.gmail.com>
 <CAFHpkQGm=ViazYmU1yYG0u-xLCudxJ1k2_r2O5uXTeCUOB73nA@mail.gmail.com>
Message-ID: <20200325132144.GF1578@mdounin.ru>

Hello!

On Tue, Mar 24, 2020 at 09:29:28PM +0500, Илья Шипицин wrote:

> выглядит это примерно так.
> 
> живешь, живешь, думаешь, что у тебя все ок.
> потом обновляешься до 1.17.9, и по логам идут 400-ки.
> 
> смотришь в error.log - там duplicate Host header (про который ты ранее и
> знать не знал, и без понятия, в чем там вообще прблема, потому что ее нет
> никакой)
> 
> какая-то абстрактная задача запретить такие хедера, задача ради самой задачи

У вас мусор в заголовках запросов, прямо запрещённый RFC и 
потенциально приводящий к security-проблемам.  В рамках очередной 
серии патчей, закрывающих подобные security-проблемы - требования 
были ужесточены, имеющийся мусор - стал приводить к 400 ошибкам.

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

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

From nginx-forum на forum.nginx.org  Wed Mar 25 13:48:10 2020
From: nginx-forum на forum.nginx.org (opan)
Date: Wed, 25 Mar 2020 09:48:10 -0400
Subject: =?UTF-8?B?UmU6INCi0LDQudC80LDRg9GC0YsgcHJveHkgcGFzcw==?=
In-Reply-To: <631231b8afc7a4b6e4198952506ca8ed.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQEn2cEf=4Y-87m1_r0R=hL4N+RwJUNXQ2g3jSn6WQgF=Q@mail.gmail.com>
 <631231b8afc7a4b6e4198952506ca8ed.NginxMailingListRussian@forum.nginx.org>
Message-ID: <730d5bd0c34dc8c1c46b74ca5b11ae13.NginxMailingListRussian@forum.nginx.org>

Добрый день.

В продолжение изучения проблемы обнаружили что в логе нжинкса
upstream_response_time - 41ms, а этот же запрос, если смотреть tcpdump,
время ответа бэка меньше 1ms:

https://www.dropbox.com/s/04falc2m073jnf5/Screenshot%202020-03-25%2016.38.15.png?dl=0


Как такое может быть?


On 23.03.2020 14:35, Илья Шипицин wrote:
> пара моментов
>
> 1) у вас proxy_pass на https, по крайней мере первоначальный хендшейк
может быть долгим (например, если клиент захочет сделать OCSP проверку).
выглядит так, как будто у вас
> должен быть кипэлайв до бекенда, поэтому это соображение должно касаться
только редких запросов
>
> 2) возможно, у вас работает буферизация запросов-ответов. попробуйте
"proxy_buffering off;" и "proxy_request_buffering off;" ?
>
> пн, 23 мар. 2020 г. в 14:01, opan <nginx-forum на forum.nginx.org>:
>
>     У нас есть одна площадка, нжинкс принимает запросы и проксирует на
бэкенд
>     через fcgi_pass. В логах нжинса мы видим upstream_response_time 40мс.
>     Появилась вторая площадка, мы принимаем там трафик и отправляем все
на
>     первую площадку через proxy_pass. Так же логируем здесь
>     upstream_reponse_time и наблюдаем очень большие значения. Мы ожидали,
что
>     добавится просто летенси между новой и старой площадкой, плюс
какие-то
>     небольшие накладные расходы nginx. Но это не так, в
upstream_response_time
>     мы видим 130-150мс ( в 3.5 раз больше, чем на площадке 1). При этом,
если
>     замерять время запросов от клиента, то total_time курла примерно
одинаков
>     для обоих площадок. Как такое может быть? Почему в логах
>     upstream_reponse_time больше в 3-4 раза, а время ответа при этом
практически
>     не меняется?
>
>     Вот фрагмент конфигурации, в которой проксируем:
>
>      location = /ххх {
>
>             proxy_cache off;
>             proxy_redirect off;
>             proxy_pass_request_body on;
>             proxy_pass_request_headers on;
>             proxy_next_upstream off;
>             proxy_set_header Host $host;
>             proxy_set_header X-Real-IP $remote_addr;
>             proxy_pass https://second.domain/xxx;
>             proxy_http_version 1.1;
>             proxy_set_header Connection "";
>
>             }
>
>     Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,287422,287422#msg-287422
>
>     _______________________________________________
>     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

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


From bgx на protva.ru  Wed Mar 25 16:09:40 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Wed, 25 Mar 2020 19:09:40 +0300
Subject: =?UTF-8?B?UmU6INCi0LDQudC80LDRg9GC0YsgcHJveHkgcGFzcw==?=
In-Reply-To: <730d5bd0c34dc8c1c46b74ca5b11ae13.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQEn2cEf=4Y-87m1_r0R=hL4N+RwJUNXQ2g3jSn6WQgF=Q@mail.gmail.com>
 <631231b8afc7a4b6e4198952506ca8ed.NginxMailingListRussian@forum.nginx.org>
 <730d5bd0c34dc8c1c46b74ca5b11ae13.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200325160940.GS14751@sie.protva.ru>

On Wed, Mar 25, 2020 at 09:48:10AM -0400, opan wrote:
> Добрый день.
> 
> В продолжение изучения проблемы обнаружили что в логе нжинкса
> upstream_response_time - 41ms, а этот же запрос, если смотреть tcpdump,
> время ответа бэка меньше 1ms:
> 
> https://www.dropbox.com/s/04falc2m073jnf5/Screenshot%202020-03-25%2016.38.15.png?dl=0
> 
> 
> Как такое может быть?

 Ответ апстрима не обязательно помещается в один пакет, даже если у него
 установлен флаг PSH. Если бы отображалось содержимое пакетов, то можно
 было бы проверить, передан ли ответ полностью, а при наличии в дампе
 ответных ACKов -- утверждать, что ответ получен сервером.
-- 
 Eugene Berdnikov

From nginx-forum на forum.nginx.org  Fri Mar 27 11:11:01 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Fri, 27 Mar 2020 07:11:01 -0400
Subject: =?UTF-8?B?0LLQt9Cw0LjQvNC+0LTQtdC50YHRgtCy0LjQtSBOZ2lueCDRgSBmY2dpINCR0JU=?=
 =?UTF-8?B?0Jcg0L/RhdC/LdGE0LDQudC70L7Qsg==?=
Message-ID: <b374813462723891d1002a7b2f9b08df.NginxMailingListRussian@forum.nginx.org>

Всем привет )
тут запускаю fcgi-демона, который тупо ловит строку текста от Nginx, а в
ответ шлёт ему соответствующую HTML-строку...
и во всех конфигах, что я нашёл в гугле, фигурируют пхп-файлы, прям
везде...
Но у меня нет пхп-файла. У меня висит демон и через сокет ловит строку.
И эту строку я вывожу в линух-консоль (для тестов) и вижу такой текст:
(тут очевидно BB-кодов нет, так что сорри, как есть...):

[I] Accepted connection on descriptor 5(host=127.0.0.1, port=41892)
count = 872
data:;
      QUERY_STRINGREQUEST_METHODGET
                                   CONTENT_TYPECONTENT_LENGTH
                                                             SCRIPT_NAME/
                                                                        
REQUEST_URI/
DOCUMENT_ROOT/usr/local/www/sites/test1.rSERVER_PROTOCOLHTTP/1.1REQUEST_SCHEMEhttpGATEWAY_INTERFACECGI/1.1
                                                                            
                             SERVER_SOFTWAREnginx/1.14.2
                                                                            
                                                          
REMOTE_ADDR127.0.0.1
                                                                            
                                                                            
  REMOTE_PORT53664
                                                                            
                                                                            
                      SERVER_ADDR127.0.0.1
    SERVER_PORT80
                SERVER_NAMEtest1.ruREDIRECT_STATUS200  HTTP_HOSTtest1.ru
HTTP_CONNECTIONkeep-alive      
HTTP_CACHE_CONTROLmax-age=0HTTP_UPGRADE_INSECURE_REQUESTS1iHTTP_USER_AGENTMozilla/5.0
(X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/80.0.3987.149 Safari/537.36
HTTP_ACCEPT_ENCODINGgzip,
deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7e/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
4096
count = -1
return false
count = 0
[I] Close 5
[I] Accepted connection on descriptor 5(host=127.0.0.1, port=41894)
count = 832
data:▒
      QUERY_STRINGREQUEST_METHODGET
                                   CONTENT_TYPECONTENT_LENGTH

                                                            
SCRIPT_NAME/favicon.ico

                                                                            
       REQUEST_URI/favicon.ico

DOCUMENT_ROOT/usr/local/www/sites/test1.rSERVER_PROTOCOLHTTP/1.1REQUEST_SCHEMEhttpGATEWAY_INTERFACECGI/1.1
DOCUMENT_URI/favicon.ico
                                                                            
                             SERVER_SOFTWAREnginx/1.14.2
                                                                            
                                                          
REMOTE_ADDR127.0.0.1
                                                                            
                                                                            
  REMOTE_PORT53664
                                                                            
                                                                            
                      SERVER_ADDR127.0.0.1
    SERVER_PORT80
                SERVER_NAMEtest1.ruREDIRECT_STATUS200  HTTP_HOSTtest1.ru
HTTP_CONNECTIONkeep-alive
                       
HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENTMozilla/5.0
(X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/80.0.3987.149 Safari/537.36
                                                                            
                                                                            
                                  
'HTTP_ACCEPTimage/webp,image/apng,image/*,*/*;q=0.8
HTTP_ACCEPT_ENCODINGgzip,
deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7
4096
count = -1
return false
count = 0
[I] Close 5


ну вот к этой строке у меня и возникают вопросы...
1. как видно, тут ДВАЖДЫ практически одно и то же (port=41894 - порт разный
2 раза)
это 2 запроса делает браузер, или Nginx, или мой демон?

2. нет пробела между названием переменной и значением

3. а тут ещё и переноса строк нет:
HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENT

4. подразумевается эти параметры обрабатывать регекспом?

5. мне столько параметров не надо, как убрать половину?

6. ОТВЕТ, который я пытаюсь записать обратно в сокет не даёт результата... Я
шлю буквально следующее:
HTTP/1.1 200 OK\r\nServer: maputa\r\nContent-Type:
text/html\r\nContent-Length: 7\r\n\r\nWisdom\r\n\r\n 

Прошу знающих поделиться мудростью )

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


From nginx-forum на forum.nginx.org  Fri Mar 27 11:15:47 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Fri, 27 Mar 2020 07:15:47 -0400
Subject: =?UTF-8?B?UmU6INCy0LfQsNC40LzQvtC00LXQudGB0YLQstC40LUgTmdpbngg0YEgZmNnaSA=?=
 =?UTF-8?B?0JHQldCXINC/0YXQvy3RhNCw0LnQu9C+0LI=?=
In-Reply-To: <b374813462723891d1002a7b2f9b08df.NginxMailingListRussian@forum.nginx.org>
References: <b374813462723891d1002a7b2f9b08df.NginxMailingListRussian@forum.nginx.org>
Message-ID: <85e76984bdd19d8bdb7d6b728efa255c.NginxMailingListRussian@forum.nginx.org>

хмм, если убрать строчку "include /etc/nginx/fastcgi.conf;",
то пришлёт такое:

[I] Accepted connection on descriptor 5(host=127.0.0.1, port=42028)
count = 504
data:� HTTP_HOSTtest1.ru
HTTP_CONNECTIONkeep-alive      
HTTP_CACHE_CONTROLmax-age=0HTTP_UPGRADE_INSECURE_REQUESTS1iHTTP_USER_AGENTMozilla/5.0
(X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/80.0.3987.149 Safari/537.36
HTTP_ACCEPT_ENCODINGgzip,
deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7e/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
4096
count = -1
return false
count = 0
[I] Close 5
[I] Accepted connection on descriptor 5(host=127.0.0.1, port=42030)
count = 432
data:� HTTP_HOSTtest1.ru
HTTP_CONNECTIONkeep-alive
                       
HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENTMozilla/5.0
(X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/80.0.3987.149 Safari/537.36
                                                                            
                                                                            
                                  
'HTTP_ACCEPTimage/webp,image/apng,image/*,*/*;q=0.8
HTTP_ACCEPT_ENCODINGgzip,
deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7
4096
count = -1
return false
count = 0
[I] Close 5

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


From nginx-forum на forum.nginx.org  Fri Mar 27 12:18:10 2020
From: nginx-forum на forum.nginx.org (opan)
Date: Fri, 27 Mar 2020 08:18:10 -0400
Subject: =?UTF-8?B?UmU6INCi0LDQudC80LDRg9GC0YsgcHJveHkgcGFzcw==?=
In-Reply-To: <20200325160940.GS14751@sie.protva.ru>
References: <20200325160940.GS14751@sie.protva.ru>
Message-ID: <a880188b1a712b993dcc9a58a7281047.NginxMailingListRussian@forum.nginx.org>

Добрый день!

1. В данном случае мы видели содержимое и ответ умещался в один пакет
2. У нас есть метрики на самом бэкенде, где мы засекаем время ответа. в 90%
оно составляет меньше <1 мс, в то время как 90 персентиль по логам нжинкса
получается 45мс.

Не может нджинкс возвращать неправильный upstream_response_time?


On 3/25/20 7:09 PM, Evgeniy Berdnikov wrote:
> On Wed, Mar 25, 2020 at 09:48:10AM -0400, opan wrote:
>> Добрый день.
>>
>> В продолжение изучения проблемы обнаружили что в логе нжинкса
>> upstream_response_time - 41ms, а этот же запрос, если смотреть tcpdump,
>> время ответа бэка меньше 1ms:
>>
>>
https://www.dropbox.com/s/04falc2m073jnf5/Screenshot%202020-03-25%2016.38.15.png?dl=0
>>
>>
>> Как такое может быть?
>
>  Ответ апстрима не обязательно помещается в один пакет, даже если у него
>  установлен флаг PSH. Если бы отображалось содержимое пакетов, то можно
>  было бы проверить, передан ли ответ полностью, а при наличии в дампе
>  ответных ACKов -- утверждать, что ответ получен сервером.

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


From valery+nginxru на grid.net.ru  Fri Mar 27 12:30:22 2020
From: valery+nginxru на grid.net.ru (Valery Kholodkov)
Date: Fri, 27 Mar 2020 13:30:22 +0100
Subject: =?UTF-8?B?UmU6INCy0LfQsNC40LzQvtC00LXQudGB0YLQstC40LUgTmdpbngg0YEgZmNnaSA=?=
 =?UTF-8?B?0JHQldCXINC/0YXQvy3RhNCw0LnQu9C+0LI=?=
In-Reply-To: <b374813462723891d1002a7b2f9b08df.NginxMailingListRussian@forum.nginx.org>
References: <b374813462723891d1002a7b2f9b08df.NginxMailingListRussian@forum.nginx.org>
Message-ID: <7bda617c-af85-cb73-28bb-1ec29cb117b0@grid.net.ru>

fastcgi вообще-то бинарный протокол. Используй libfcgi. Вот пример:

https://github.com/vkholodkov/fcgi-cpp-appserver
https://github.com/vkholodkov/fcgi-cpp-appserver/blob/master/src/server/fcgi_server.cpp

On 27-03-20 12:11, greenwar wrote:
> Всем привет )
> тут запускаю fcgi-демона, который тупо ловит строку текста от Nginx, а в
> ответ шлёт ему соответствующую HTML-строку...
> и во всех конфигах, что я нашёл в гугле, фигурируют пхп-файлы, прям
> везде...
> Но у меня нет пхп-файла. У меня висит демон и через сокет ловит строку.
> И эту строку я вывожу в линух-консоль (для тестов) и вижу такой текст:
> (тут очевидно BB-кодов нет, так что сорри, как есть...):
> 
> [I] Accepted connection on descriptor 5(host=127.0.0.1, port=41892)
> count = 872
> data:;
>        QUERY_STRINGREQUEST_METHODGET
>                                     CONTENT_TYPECONTENT_LENGTH
>                                                               SCRIPT_NAME/
>                                                                          
> REQUEST_URI/
> DOCUMENT_ROOT/usr/local/www/sites/test1.rSERVER_PROTOCOLHTTP/1.1REQUEST_SCHEMEhttpGATEWAY_INTERFACECGI/1.1
>                                                                              
>                               SERVER_SOFTWAREnginx/1.14.2
>                                                                              
>                                                            
> REMOTE_ADDR127.0.0.1
>                                                                              
>                                                                              
>    REMOTE_PORT53664
>                                                                              
>                                                                              
>                        SERVER_ADDR127.0.0.1
>      SERVER_PORT80
>                  SERVER_NAMEtest1.ruREDIRECT_STATUS200  HTTP_HOSTtest1.ru
> HTTP_CONNECTIONkeep-alive
> HTTP_CACHE_CONTROLmax-age=0HTTP_UPGRADE_INSECURE_REQUESTS1iHTTP_USER_AGENTMozilla/5.0
> (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
> Chrome/80.0.3987.149 Safari/537.36
> HTTP_ACCEPT_ENCODINGgzip,
> deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7e/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
> 4096
> count = -1
> return false
> count = 0
> [I] Close 5
> [I] Accepted connection on descriptor 5(host=127.0.0.1, port=41894)
> count = 832
> data:▒
>        QUERY_STRINGREQUEST_METHODGET
>                                     CONTENT_TYPECONTENT_LENGTH
> 
>                                                              
> SCRIPT_NAME/favicon.ico
> 
>                                                                              
>         REQUEST_URI/favicon.ico
> 
> DOCUMENT_ROOT/usr/local/www/sites/test1.rSERVER_PROTOCOLHTTP/1.1REQUEST_SCHEMEhttpGATEWAY_INTERFACECGI/1.1
> DOCUMENT_URI/favicon.ico
>                                                                              
>                               SERVER_SOFTWAREnginx/1.14.2
>                                                                              
>                                                            
> REMOTE_ADDR127.0.0.1
>                                                                              
>                                                                              
>    REMOTE_PORT53664
>                                                                              
>                                                                              
>                        SERVER_ADDR127.0.0.1
>      SERVER_PORT80
>                  SERVER_NAMEtest1.ruREDIRECT_STATUS200  HTTP_HOSTtest1.ru
> HTTP_CONNECTIONkeep-alive
>                         
> HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENTMozilla/5.0
> (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
> Chrome/80.0.3987.149 Safari/537.36
>                                                                              
>                                                                              
>                                    
> 'HTTP_ACCEPTimage/webp,image/apng,image/*,*/*;q=0.8
> HTTP_ACCEPT_ENCODINGgzip,
> deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7
> 4096
> count = -1
> return false
> count = 0
> [I] Close 5
> 
> 
> ну вот к этой строке у меня и возникают вопросы...
> 1. как видно, тут ДВАЖДЫ практически одно и то же (port=41894 - порт разный
> 2 раза)
> это 2 запроса делает браузер, или Nginx, или мой демон?
> 
> 2. нет пробела между названием переменной и значением
> 
> 3. а тут ещё и переноса строк нет:
> HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENT
> 
> 4. подразумевается эти параметры обрабатывать регекспом?
> 
> 5. мне столько параметров не надо, как убрать половину?
> 
> 6. ОТВЕТ, который я пытаюсь записать обратно в сокет не даёт результата... Я
> шлю буквально следующее:
> HTTP/1.1 200 OK\r\nServer: maputa\r\nContent-Type:
> text/html\r\nContent-Length: 7\r\n\r\nWisdom\r\n\r\n
> 
> Прошу знающих поделиться мудростью )


-- 
Val

From mdounin на mdounin.ru  Fri Mar 27 12:49:56 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Fri, 27 Mar 2020 15:49:56 +0300
Subject: =?UTF-8?B?UmU6INCi0LDQudC80LDRg9GC0YsgcHJveHkgcGFzcw==?=
In-Reply-To: <a880188b1a712b993dcc9a58a7281047.NginxMailingListRussian@forum.nginx.org>
References: <20200325160940.GS14751@sie.protva.ru>
 <a880188b1a712b993dcc9a58a7281047.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200327124956.GC3546@mdounin.ru>

Hello!

On Fri, Mar 27, 2020 at 08:18:10AM -0400, opan wrote:

> Добрый день!
> 
> 1. В данном случае мы видели содержимое и ответ умещался в один пакет
> 2. У нас есть метрики на самом бэкенде, где мы засекаем время ответа. в 90%
> оно составляет меньше <1 мс, в то время как 90 персентиль по логам нжинкса
> получается 45мс.
> 
> Не может нджинкс возвращать неправильный upstream_response_time?

Тут важно понимать, что:

1. $upstream_response_time включает в себя не только получение 
ответа, но и отправку запроса, а также установление соединения 
(а равно резолвинг адресов, если он используется, и SSL handshake, 
если используется SSL).

2. В зависимости от конкретной формы ответа - окончание ответа 
может индицироваться закрытием соединения, и даже если кажется, 
что весь ответ "влез" в один пакет - это может быть не так, ибо 
ответ не закончен, пока не пришёл FIN.  А FIN может придти совсем 
в другое время.

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

4. В одном рабочем процессе nginx'а обрабатывается множество 
соединений, так что если в том же рабочем процессе 
происходит что-то ещё тяжёлое (а особенно - если что-то 
блокирующееся, несмотря на явные рекомендации так не делать) - до 
конкретного соединения дело может доходить с заметной задержкой.

5. Время в nginx'е обновляется один раз за цикл обработки 
соединений, и если, опять же, в том же рабочем процессе происходит 
что-то ещё тяжёлое - время может быть неточным, даже если 
конкретному запросу повезло и обработка была быстрой.

Что конкретно происходит у вас - неизвестно, данных для анализа 
недостаточно.

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

From pavel2000 на ngs.ru  Fri Mar 27 14:08:24 2020
From: pavel2000 на ngs.ru (Pavel)
Date: Fri, 27 Mar 2020 21:08:24 +0700
Subject: =?UTF-8?B?UmU6INCy0LfQsNC40LzQvtC00LXQudGB0YLQstC40LUgTmdpbngg0YEgZmNnaSA=?=
 =?UTF-8?B?0JHQldCXINC/0YXQvy3RhNCw0LnQu9C+0LI=?=
In-Reply-To: <7bda617c-af85-cb73-28bb-1ec29cb117b0@grid.net.ru>
References: <b374813462723891d1002a7b2f9b08df.NginxMailingListRussian@forum.nginx.org>
 <7bda617c-af85-cb73-28bb-1ec29cb117b0@grid.net.ru>
Message-ID: <6ad4221e-9f85-41a4-c34c-493224c9f311@ngs.ru>

27.03.2020 19:30, Valery Kholodkov пишет:
> fastcgi вообще-то бинарный протокол. Используй libfcgi. Вот пример:
>
> https://github.com/vkholodkov/fcgi-cpp-appserver
> https://github.com/vkholodkov/fcgi-cpp-appserver/blob/master/src/server/fcgi_server.cpp 
>

Извините за оффтоп, но не подскажет ли кто готового решения простого 
клиента fastcgi (отправить запрос за статистикой php fpm) на pure C
(ищется для использования в  Collectd модуле php-fpm). Как-то не нахожу 
времени самому разобраться и написать, а готового не подвернулось.

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

>
> On 27-03-20 12:11, greenwar wrote:
>> Всем привет )
>> тут запускаю fcgi-демона, который тупо ловит строку текста от Nginx, а в
>> ответ шлёт ему соответствующую HTML-строку...
>> и во всех конфигах, что я нашёл в гугле, фигурируют пхп-файлы, прям
>> везде...
>> Но у меня нет пхп-файла. У меня висит демон и через сокет ловит строку.
>> И эту строку я вывожу в линух-консоль (для тестов) и вижу такой текст:
>> (тут очевидно BB-кодов нет, так что сорри, как есть...):
>>
>> [I] Accepted connection on descriptor 5(host=127.0.0.1, port=41892)
>> count = 872
>> data:;
>>        QUERY_STRINGREQUEST_METHODGET
>>                                     CONTENT_TYPECONTENT_LENGTH
>> SCRIPT_NAME/
>> REQUEST_URI/
>> DOCUMENT_ROOT/usr/local/www/sites/test1.rSERVER_PROTOCOLHTTP/1.1REQUEST_SCHEMEhttpGATEWAY_INTERFACECGI/1.1 
>>
>>                               SERVER_SOFTWAREnginx/1.14.2
>> REMOTE_ADDR127.0.0.1
>>    REMOTE_PORT53664
>>                        SERVER_ADDR127.0.0.1
>>      SERVER_PORT80
>>                  SERVER_NAMEtest1.ruREDIRECT_STATUS200 HTTP_HOSTtest1.ru
>> HTTP_CONNECTIONkeep-alive
>> HTTP_CACHE_CONTROLmax-age=0HTTP_UPGRADE_INSECURE_REQUESTS1iHTTP_USER_AGENTMozilla/5.0 
>>
>> (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
>> Chrome/80.0.3987.149 Safari/537.36
>> HTTP_ACCEPT_ENCODINGgzip,
>> deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7e/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 
>>
>> 4096
>> count = -1
>> return false
>> count = 0
>> [I] Close 5
>> [I] Accepted connection on descriptor 5(host=127.0.0.1, port=41894)
>> count = 832
>> data:▒
>>        QUERY_STRINGREQUEST_METHODGET
>>                                     CONTENT_TYPECONTENT_LENGTH
>>
>> SCRIPT_NAME/favicon.ico
>>
>>         REQUEST_URI/favicon.ico
>>
>> DOCUMENT_ROOT/usr/local/www/sites/test1.rSERVER_PROTOCOLHTTP/1.1REQUEST_SCHEMEhttpGATEWAY_INTERFACECGI/1.1 
>>
>> DOCUMENT_URI/favicon.ico
>>                               SERVER_SOFTWAREnginx/1.14.2
>> REMOTE_ADDR127.0.0.1
>>    REMOTE_PORT53664
>>                        SERVER_ADDR127.0.0.1
>>      SERVER_PORT80
>>                  SERVER_NAMEtest1.ruREDIRECT_STATUS200 HTTP_HOSTtest1.ru
>> HTTP_CONNECTIONkeep-alive
>> HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENTMozilla/5.0
>> (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
>> Chrome/80.0.3987.149 Safari/537.36
>> 'HTTP_ACCEPTimage/webp,image/apng,image/*,*/*;q=0.8
>> HTTP_ACCEPT_ENCODINGgzip,
>> deflate#HTTP_ACCEPT_LANGUAGEru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7
>> 4096
>> count = -1
>> return false
>> count = 0
>> [I] Close 5
>>
>>
>> ну вот к этой строке у меня и возникают вопросы...
>> 1. как видно, тут ДВАЖДЫ практически одно и то же (port=41894 - порт 
>> разный
>> 2 раза)
>> это 2 запроса делает браузер, или Nginx, или мой демон?
>>
>> 2. нет пробела между названием переменной и значением
>>
>> 3. а тут ещё и переноса строк нет:
>> HTTP_PRAGMAno-cachHTTP_CACHE_CONTROLno-cacheiHTTP_USER_AGENT
>>
>> 4. подразумевается эти параметры обрабатывать регекспом?
>>
>> 5. мне столько параметров не надо, как убрать половину?
>>
>> 6. ОТВЕТ, который я пытаюсь записать обратно в сокет не даёт 
>> результата... Я
>> шлю буквально следующее:
>> HTTP/1.1 200 OK\r\nServer: maputa\r\nContent-Type:
>> text/html\r\nContent-Length: 7\r\n\r\nWisdom\r\n\r\n
>>
>> Прошу знающих поделиться мудростью )
>
>


From sytar.alex на gmail.com  Fri Mar 27 14:50:08 2020
From: sytar.alex на gmail.com (Aleksandr Sytar)
Date: Fri, 27 Mar 2020 17:50:08 +0300
Subject: =?UTF-8?B?UmU6INCy0LfQsNC40LzQvtC00LXQudGB0YLQstC40LUgTmdpbngg0YEgZmNnaSA=?=
 =?UTF-8?B?0JHQldCXINC/0YXQvy3RhNCw0LnQu9C+0LI=?=
In-Reply-To: <b374813462723891d1002a7b2f9b08df.NginxMailingListRussian@forum.nginx.org>
References: <b374813462723891d1002a7b2f9b08df.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAKqRTSHUHtKec5Wp7zVrrZ1Dufary9kz+aKqrs277bYxVV7DFQ@mail.gmail.com>

пт, 27 мар. 2020 г. в 14:11, greenwar <nginx-forum на forum.nginx.org>:

>
>
> Прошу знающих поделиться мудростью )
>
>
http://www.mit.edu/~yandros/doc/specs/fcgi-spec.html

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

From nginx-forum на forum.nginx.org  Sat Mar 28 07:46:27 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Sat, 28 Mar 2020 03:46:27 -0400
Subject: =?UTF-8?B?UmU6INCy0LfQsNC40LzQvtC00LXQudGB0YLQstC40LUgTmdpbngg0YEgZmNnaSA=?=
 =?UTF-8?B?0JHQldCXINC/0YXQvy3RhNCw0LnQu9C+0LI=?=
In-Reply-To: <7bda617c-af85-cb73-28bb-1ec29cb117b0@grid.net.ru>
References: <7bda617c-af85-cb73-28bb-1ec29cb117b0@grid.net.ru>
Message-ID: <046bddc6089c303126d605a2cc81dcf6.NginxMailingListRussian@forum.nginx.org>

> fastcgi вообще-то бинарный протокол.

а что именно это означает, как взаимодействие то выглядит?
в fcgi_server.cpp используются файлы:
#include <fcgiapp.h>
#include <fcgio.h>

но у меня таких нет
и "apt install libfcgi" - их не добавил
или добавил, но хз куда

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


From red-fox0 на ya.ru  Sat Mar 28 07:52:49 2020
From: red-fox0 на ya.ru (fox)
Date: Sat, 28 Mar 2020 14:52:49 +0700
Subject: =?UTF-8?B?UmU6INCy0LfQsNC40LzQvtC00LXQudGB0YLQstC40LUgTmdpbngg0YEgZmNnaSA=?=
 =?UTF-8?B?0JHQldCXINC/0YXQvy3RhNCw0LnQu9C+0LI=?=
In-Reply-To: <046bddc6089c303126d605a2cc81dcf6.NginxMailingListRussian@forum.nginx.org>
References: <7bda617c-af85-cb73-28bb-1ec29cb117b0@grid.net.ru>
 <046bddc6089c303126d605a2cc81dcf6.NginxMailingListRussian@forum.nginx.org>
Message-ID: <7cd25265-765d-1ad2-3290-ebea8eb98249@ya.ru>

apt install libfcgi-dev

28.03.2020 14:46, greenwar пишет:
>> fastcgi вообще-то бинарный протокол.
> 
> а что именно это означает, как взаимодействие то выглядит?
> в fcgi_server.cpp используются файлы:
> #include <fcgiapp.h>
> #include <fcgio.h>
> 
> но у меня таких нет
> и "apt install libfcgi" - их не добавил
> или добавил, но хз куда
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287478,287498#msg-287498
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 


From nginx-forum на forum.nginx.org  Sat Mar 28 10:02:15 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Sat, 28 Mar 2020 06:02:15 -0400
Subject: =?UTF-8?Q?Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?=
Message-ID: <da5880a794b49f3e41126987df287f52.NginxMailingListRussian@forum.nginx.org>

наткнулся тут на интересный тред, где предлагается реализовать что-то вроде
модуля под Nginx через вебсокеты:
https://www.linux.org.ru/forum/development/12702791

> В курсе. Поэтому и удивляюсь, зачем нужен FastCGI, когда есть HTTP и
WebSockets и соответствующие либы.

Вот и возник вопрос, нужен ли FastCGI на самом деле мне...
У меня изначально была мысль реализовать через модуль Nginx, но как-то
отговорили...
Таки что конкретно предлагается в том треде, можете пояснить, как это будет
внутри Nginx выглядеть?
Сейчас чтобы Nginx передал HTTP-инфу демону нужно это делать через параметр
"fastcgi_pass ..."
А там что предлагается?
Я запутался... чтобы вебсокет создать надо HTML-код передать с JS, который
этот вебсокет создаст! хм...
как это всё должно работать?

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


From nginx-forum на forum.nginx.org  Sat Mar 28 22:35:58 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Sat, 28 Mar 2020 18:35:58 -0400
Subject: =?UTF-8?B?UmU6INCy0LfQsNC40LzQvtC00LXQudGB0YLQstC40LUgTmdpbngg0YEgZmNnaSA=?=
 =?UTF-8?B?0JHQldCXINC/0YXQvy3RhNCw0LnQu9C+0LI=?=
In-Reply-To: <CAKqRTSHUHtKec5Wp7zVrrZ1Dufary9kz+aKqrs277bYxVV7DFQ@mail.gmail.com>
References: <CAKqRTSHUHtKec5Wp7zVrrZ1Dufary9kz+aKqrs277bYxVV7DFQ@mail.gmail.com>
Message-ID: <85269cad112f95dcf36d9a2b0bcbe0c5.NginxMailingListRussian@forum.nginx.org>

Aleksandr Sytar Wrote:
-------------------------------------------------------
> пт, 27 мар. 2020 г. в 14:11, greenwar <nginx-forum на forum.nginx.org>:
> 
> >
> >
> > Прошу знающих поделиться мудростью )
> >
> >
> http://www.mit.edu/~yandros/doc/specs/fcgi-spec.html
> 
> Не благодарите.
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


читаю там:
A FastCGI application calls accept() on the socket referred to by file
descriptor FCGI_LISTENSOCK_FILENO to accept a new transport connection. If
the accept() succeeds, and the FCGI_WEB_SERVER_ADDRS environment variable is
bound, the application application immediately performs the following
special processing:

потом грепаю сырцы найденных в сети fcgi-серверов (с буста, с гитхаба - у
меня 3 штуки)
и не нахожу там таких переменных/дескрипторов вообще...
КАК это всё применить к Nginx ?

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


From valery+nginxru на grid.net.ru  Mon Mar 30 09:10:29 2020
From: valery+nginxru на grid.net.ru (Valery Kholodkov)
Date: Mon, 30 Mar 2020 11:10:29 +0200
Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?=
In-Reply-To: <da5880a794b49f3e41126987df287f52.NginxMailingListRussian@forum.nginx.org>
References: <da5880a794b49f3e41126987df287f52.NginxMailingListRussian@forum.nginx.org>
Message-ID: <4e0c8966-573d-ff3a-f723-f7c9dc6d5ae7@grid.net.ru>

Вот и я спрашиваю: зачем тебе FastCGI если есть HTTP? FastCGI -- древний 
протокол, документации толком в онлайне уже похоже нет.

Нужна высокая производительность? Сделай сервер на node.js или Golang, 
запроксируй его и будет счастие.

On 28-03-20 11:02, greenwar wrote:
> наткнулся тут на интересный тред, где предлагается реализовать что-то вроде
> модуля под Nginx через вебсокеты:
> https://www.linux.org.ru/forum/development/12702791
> 
>> В курсе. Поэтому и удивляюсь, зачем нужен FastCGI, когда есть HTTP и
> WebSockets и соответствующие либы.
> 
> Вот и возник вопрос, нужен ли FastCGI на самом деле мне...
> У меня изначально была мысль реализовать через модуль Nginx, но как-то
> отговорили...
> Таки что конкретно предлагается в том треде, можете пояснить, как это будет
> внутри Nginx выглядеть?
> Сейчас чтобы Nginx передал HTTP-инфу демону нужно это делать через параметр
> "fastcgi_pass ..."
> А там что предлагается?
> Я запутался... чтобы вебсокет создать надо HTML-код передать с JS, который
> этот вебсокет создаст! хм...
> как это всё должно работать?


-- 
Val

From nginx-forum на forum.nginx.org  Mon Mar 30 10:42:14 2020
From: nginx-forum на forum.nginx.org (greenwar)
Date: Mon, 30 Mar 2020 06:42:14 -0400
Subject: =?UTF-8?Q?Re=3A_Nginx_+_WebSockets_=D0=BD=D0=B0_C/C++?=
In-Reply-To: <4e0c8966-573d-ff3a-f723-f7c9dc6d5ae7@grid.net.ru>
References: <4e0c8966-573d-ff3a-f723-f7c9dc6d5ae7@grid.net.ru>
Message-ID: <513dbcb08d15ebb206aa097f4f5d41c4.NginxMailingListRussian@forum.nginx.org>

нет, не подходит ни то, ни другое
нужен C/C++

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