From nginx-forum на forum.nginx.org Sun Sep 1 18:36:37 2019 From: nginx-forum на forum.nginx.org (grey) Date: Sun, 01 Sep 2019 14:36:37 -0400 Subject: =?UTF-8?B?0JfQsNC80LXRgtC40Lsg0LXRidC1INGH0YLQviDQsiDQu9C+0LPQsNGFINGA0LU=?= =?UTF-8?B?0LTQvdC+INC/0YDQvtGB0LrQsNC60LjQstCw0LXRgiBTU0wgcmVhZCgpIGZh?= =?UTF-8?B?aWxlZA==?= Message-ID: Привет! Вот ошибка: 2019/09/01 21:30:07 [crit] 1512#1784: *29234169 SSL_read() failed (SSL: error:14191044:SSL routines:tls1_enc:internal error) while waiting for request, client: 109.252.*.*, server: 0.0.0.0:443 версия 1.17.2 Это с чем связно? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285502,285502#msg-285502 From igor.bliss на gmail.com Mon Sep 2 07:21:07 2019 From: igor.bliss на gmail.com (Igor Savenko) Date: Mon, 2 Sep 2019 10:21:07 +0300 Subject: common location for all virtual hosts Message-ID: Добрый день! Есть задача сделать общий location для всех virtual hosts, чтобы при выполнении определенного условия происходил inner redirect на этот location из любого virtualhost. Можно хоть намек, как это сделать программно, в модуле? На уровне конфига, похоже, не получится -- нужно будет скорее всего делать в каждом virtual host include конфига с этим location. Спасибо! ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Sep 2 11:55:35 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 2 Sep 2019 14:55:35 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC/0L7Qu9C90L7RgdGC0YzRjiDQt9Cw0LPRgNGD0LbQsNC10YIg?= =?UTF-8?B?0LLQtdGB0Ywg0L/RgNC+0YbQtdGB0YHQvtGAINC/0YDQuCByZWxvYWQnZQ==?= In-Reply-To: References: <342fa0ac-f792-e639-0887-468322a59a36@gmail.com> <20190830124912.GE1877@mdounin.ru> Message-ID: <20190902115535.GO1877@mdounin.ru> Hello! On Sat, Aug 31, 2019 at 12:54:06PM +0500, Dmitry Sergeev wrote: > Добрый день! > Спасибо за ответ. > > Конфиг полный, просто сократил количетсво виртуальных хостов, так как они одинаковые. В конфиге значилось: include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; Так что понять по нему, полный он, или нет - не представляется возможным, отсюда и вопросы. > ssl_session_cache - действительно не настроено. > ssl_dhparam - аналогично. > сертификат один общий для всех, сгенерировал его для wildcard домена от let's encrypt (Signature Algorithm: sha256WithRSAEncryption, Public-Key: rsaEncryption (2048 bit)). > > Пытался оптимизировать ssl и посмотреть влияние его настроек на эту проблему. В частности пробовал глобально добавлять опции: > > *ssl_session_cache shared:SSL:20m;* > *ssl_session_timeout 30m; *вроде никак не влияло, но я проверю еще раз конечно, и более чательно. Если большая часть клиентов использует тикеты - то может и не повлиять. Для теста можно попробовать отключить тикеты (ssl_session_tickets) и/или настроить внешний ключ (ssl_session_ticket_key), так как автоматически сгенерированные ключи при reload'е обновляются. > Про ssl_dhparam не понял, с точки зрения производительности - > его лучше добавлять но с небольшой битностью (2048 и меньше) или > лучше совсем не использовать? Лучше - не использовать. Даже 2048 для классического Диффи-Хеллмана - это очень медленно. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Mon Sep 2 13:38:30 2019 From: nginx-forum на forum.nginx.org (grey) Date: Mon, 02 Sep 2019 09:38:30 -0400 Subject: =?UTF-8?B?0J7RiNC40LHQutCwICJbd2Fybl0gY29uZmxpY3Rpbmcgc2VydmVyIG5hbWUgInNp?= =?UTF-8?B?dGUucnUiIG9uIDAuMC4wLjA6ODAsIGlnbm9yZWQi?= Message-ID: <96beae5dd6e585b43f2e7418f47278fd.NginxMailingListRussian@forum.nginx.org> Приветствую. Решил перевести сайт на https, заодно убрать www в имени домена. Раньше делал это через if-ы, но тут говорят, что они зло, потому захотел сделать всё по уму... # редирект с http на https server { listen 80; server_name site.ru www.site.ru; return 301 https://site.ru$request_uri; } # редирект с www на non-www server { server_name www.site.ru; # <------------ ошибка rewrite ^(.*)$ https://site.ru$1 permanent; } server { listen 443 ssl default_server; server_name site.ru; ... В результате получаю ошибку "[warn] conflicting server name "www.site.ru" on 0.0.0.0:80, ignored". Ругает на строку "server_name www.site.ru;", но как сделать по другому - не пойму. Убрать строку наверно будет не правильно, т.к. хостов может быть много, а мне нужно для конкретного хоста сделать те или иные манипуляции. Подскажите, плз, что я делаю не так? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285510,285510#msg-285510 From mdounin на mdounin.ru Mon Sep 2 13:40:47 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 2 Sep 2019 16:40:47 +0300 Subject: =?UTF-8?B?UmU6INCX0LDQvNC10YLQuNC7INC10YnQtSDRh9GC0L4g0LIg0LvQvtCz0LDRhSA=?= =?UTF-8?B?0YDQtdC00L3QviDQv9GA0L7RgdC60LDQutC40LLQsNC10YIgU1NMIHJlYWQo?= =?UTF-8?B?KSBmYWlsZWQ=?= In-Reply-To: References: Message-ID: <20190902134046.GP1877@mdounin.ru> Hello! On Sun, Sep 01, 2019 at 02:36:37PM -0400, grey wrote: > Вот ошибка: > > 2019/09/01 21:30:07 [crit] 1512#1784: *29234169 SSL_read() failed (SSL: > error:14191044:SSL routines:tls1_enc:internal error) while waiting for > request, client: 109.252.*.*, server: 0.0.0.0:443 > > версия 1.17.2 > > Это с чем связно? Причина "internal error" как бы намекает, что проблема где-то внутри OpenSSL. Если смотреть на код функции tls1_enc() - то это преимущественно ситуации, которых быть не должно. С редкими вкраплениями ошибок от разных других вызываемых функций - но в этом случае на стеке ошибок скорее всего будет что-то ещё. Что именно служит причиной - надо подробно разбираться с кодом OpenSSL и конкретной ситуацией. Скорее всего - какая-то ошибка в обработке краевых случаев в OpenSSL. Скажем, может быть к подобной ошибке приводит что-нибудь вроде закрытия соединения в неподходящий момент. Впрочем, если речь идёт про винды - то может быть вообще всё, что угодно. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Mon Sep 2 13:48:50 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 2 Sep 2019 16:48:50 +0300 Subject: common location for all virtual hosts In-Reply-To: References: Message-ID: <20190902134850.GQ1877@mdounin.ru> Hello! On Mon, Sep 02, 2019 at 10:21:07AM +0300, Igor Savenko wrote: > Добрый день! Есть задача сделать общий location для всех virtual hosts, > чтобы при выполнении определенного условия происходил inner redirect на > этот location из любого virtualhost. Можно хоть намек, как это сделать > программно, в модуле? На уровне конфига, похоже, не получится -- нужно > будет скорее всего делать в каждом virtual host include конфига с этим > location. Спасибо! Общих location'ов для разных виртуальных хостов - в nginx'е не бывает. Одинаковые - проще всего сделать с помощью директивы include и соответствующего конфигурационного файла. Отмечу на всякий случай, что "одинаковые" - это достаточно условное понятие, так как в любой location наследуется конфигурация с предыдущих уровней, и если значения каких-то директив в блоках server{} различаются, то и результирующая конфигурация соответствующих location'ов будет разная. -- Maxim Dounin http://mdounin.ru/ From pavel2000 на ngs.ru Mon Sep 2 13:52:38 2019 From: pavel2000 на ngs.ru (Pavel) Date: Mon, 2 Sep 2019 20:52:38 +0700 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCAiW3dhcm5dIGNvbmZsaWN0aW5nIHNlcnZlciBuYW1l?= =?UTF-8?B?ICJzaXRlLnJ1IiBvbiAwLjAuMC4wOjgwLCBpZ25vcmVkIg==?= In-Reply-To: <96beae5dd6e585b43f2e7418f47278fd.NginxMailingListRussian@forum.nginx.org> References: <96beae5dd6e585b43f2e7418f47278fd.NginxMailingListRussian@forum.nginx.org> Message-ID: 02.09.2019 20:38, grey пишет: > Приветствую. > > [cut] > > В результате получаю ошибку "[warn] conflicting server name "www.site.ru" on > 0.0.0.0:80, ignored". Ругает на строку "server_name www.site.ru;", но как > сделать по другому - не пойму. Убрать строку наверно будет не правильно, > т.к. хостов может быть много, а мне нужно для конкретного хоста сделать те > или иные манипуляции. > > Подскажите, плз, что я делаю не так? Насколько я понял по комментарию "редирект с www на non-www", первый блок используется для httP, второй блок используется для httpS  с "www", третий блок используется для httpS без "www". Тогда во втором блоке отсутствует директива "listen 443 ssl;" и настройка сертификата. __ My ICQ 12.....27 > From mdounin на mdounin.ru Mon Sep 2 14:02:59 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 2 Sep 2019 17:02:59 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCAiW3dhcm5dIGNvbmZsaWN0aW5nIHNlcnZlciBuYW1l?= =?UTF-8?B?ICJzaXRlLnJ1IiBvbiAwLjAuMC4wOjgwLCBpZ25vcmVkIg==?= In-Reply-To: <96beae5dd6e585b43f2e7418f47278fd.NginxMailingListRussian@forum.nginx.org> References: <96beae5dd6e585b43f2e7418f47278fd.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190902140259.GS1877@mdounin.ru> Hello! On Mon, Sep 02, 2019 at 09:38:30AM -0400, grey wrote: > Приветствую. > > > Решил перевести сайт на https, заодно убрать www в имени домена. Раньше > делал это через if-ы, но тут говорят, что они зло, потому захотел сделать > всё по уму... > > # редирект с http на https > server { > listen 80; > server_name site.ru www.site.ru; > return 301 https://site.ru$request_uri; > } > > # редирект с www на non-www > server { > server_name www.site.ru; # <------------ ошибка > rewrite ^(.*)$ https://site.ru$1 permanent; > } > > server { > listen 443 ssl default_server; > server_name site.ru; > ... > > > В результате получаю ошибку "[warn] conflicting server name "www.site.ru" on > 0.0.0.0:80, ignored". Ругает на строку "server_name www.site.ru;", но как > сделать по другому - не пойму. Убрать строку наверно будет не правильно, > т.к. хостов может быть много, а мне нужно для конкретного хоста сделать те > или иные манипуляции. > > Подскажите, плз, что я делаю не так? У вас имя "www.site.ru" для порта 80 используется и в первом, и во втором блоке server{}. Это не имеет смысла, так как запрос может быть обработан только в одном блоке server{}. То есть в данном конкретном конфиге - второй блок server{}, фактически, не имеет смысла. Именно из-за этого nginx и ругается. Подозреваю, что на самом деле второй блок server{} должен был быть про перенаправление с www на без-www для https, то есть содержать "listen 443 ssl;". -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Mon Sep 2 14:25:06 2019 From: nginx-forum на forum.nginx.org (pavlusha23) Date: Mon, 02 Sep 2019 10:25:06 -0400 Subject: =?UTF-8?B?0JLQvtC/0YDQtdC60Lgg0YPRgtCy0LXRgNC20LTQtdC90LjRj9C8INCyIGNoYW5n?= =?UTF-8?B?ZWxvZyDQvdC10YIg0L/QvtC00LTQtdGA0LbQutC4IHBvbGwg0LzQtdGC0L4=?= =?UTF-8?B?0LTQsCDQsiBXaW5kb3dz?= Message-ID: Вопреки утверждениям в changelog никакой поддержки poll метода в Windows не появилось, пробовал как стабильную версию, так и разрабатываемую. Скачал оба файла, ни в стабильной ветке ни в основной этой фичи не нашел. Пишет такой метод не поддерживается. Нехорошо( *) Добавление: метод poll теперь доступен на Windows при использовании Windows Vista и новее. Объявив новую фичу вы даже забыли добавить её компиляцию для Windows сборки, жесть( Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285516,285516#msg-285516 From mdounin на mdounin.ru Mon Sep 2 14:32:50 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 2 Sep 2019 17:32:50 +0300 Subject: =?UTF-8?B?UmU6INCY0L3QvtCz0LTQsCDQsiDQu9C+0LPQsNGFINC/0YDQvtGB0LrQsNC60Lg=?= =?UTF-8?B?0LLQsNC10YIgU1NMIHdyaXRlKCkgZmFpbGVk?= In-Reply-To: <16381e2350e45f6651e81c5d1723352c.NginxMailingListRussian@forum.nginx.org> References: <2156144001daba78f7ced0136e6af0ef.NginxMailingListRussian@forum.nginx.org> <16381e2350e45f6651e81c5d1723352c.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190902143250.GU1877@mdounin.ru> Hello! On Fri, Aug 30, 2019 at 11:08:54AM -0400, spanjokus wrote: > У меня такое то же иногда проскакивает, был бы признателен, если бы кто-то > подсказал из-за чего это http://mailman.nginx.org/pipermail/nginx-ru/2019-August/062366.html -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Mon Sep 2 14:48:47 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 2 Sep 2019 17:48:47 +0300 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0LXQutC4INGD0YLQstC10YDQttC00LXQvdC40Y/QvCDQsiBj?= =?UTF-8?B?aGFuZ2Vsb2cg0L3QtdGCINC/0L7QtNC00LXRgNC20LrQuCBwb2xsINC80LU=?= =?UTF-8?B?0YLQvtC00LAg0LIgV2luZG93cw==?= In-Reply-To: References: Message-ID: <20190902144847.GV1877@mdounin.ru> Hello! On Mon, Sep 02, 2019 at 10:25:06AM -0400, pavlusha23 wrote: > Вопреки утверждениям в changelog никакой поддержки poll метода в Windows не > появилось, пробовал как стабильную версию, так и разрабатываемую. Скачал оба > файла, ни в стабильной ветке ни в основной этой фичи не нашел. Пишет такой > метод не поддерживается. Нехорошо( > > *) Добавление: метод poll теперь доступен на Windows при использовании > Windows Vista и новее. > > Объявив новую фичу вы даже забыли добавить её компиляцию для Windows > сборки, жесть( Доступность метода poll определяется во время выполнения, и зависит от используемой версии Windows. Что-либо добавлять также не надо - методы select и poll на Windows собираются автоматически. Если у вас что-то не работает, а вы считаете, что должно, начните с простого: покажите ошибку, а равно лог запуска на уровне info или подробнее. Ну и укажите версию Windows, которую вы используете. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Mon Sep 2 15:45:31 2019 From: nginx-forum на forum.nginx.org (pavlusha23) Date: Mon, 02 Sep 2019 11:45:31 -0400 Subject: =?UTF-8?B?UmU6INCS0L7Qv9GA0LXQutC4INGD0YLQstC10YDQttC00LXQvdC40Y/QvCDQsiBj?= =?UTF-8?B?aGFuZ2Vsb2cg0L3QtdGCINC/0L7QtNC00LXRgNC20LrQuCBwb2xsINC80LU=?= =?UTF-8?B?0YLQvtC00LAg0LIgV2luZG93cw==?= In-Reply-To: <20190902144847.GV1877@mdounin.ru> References: <20190902144847.GV1877@mdounin.ru> Message-ID: <4e488f74f6d2c62ac6b731f823e0be3e.NginxMailingListRussian@forum.nginx.org> Отбой, терминал запускал тот Nginx что в path прописан (14-ю версию старую). А при проверке версии скачанного файла руками в другой консоли видел актуальную версию (ибо напрямую из папки). Извиняюсь за беспокойство, тему можно удалить. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285516,285520#msg-285520 From identw на gmail.com Mon Sep 2 15:54:51 2019 From: identw на gmail.com (Dmitry Sergeev) Date: Mon, 2 Sep 2019 20:54:51 +0500 Subject: =?UTF-8?B?UmU6IG5naW54INC/0L7Qu9C90L7RgdGC0YzRjiDQt9Cw0LPRgNGD0LbQsNC10YIg?= =?UTF-8?B?0LLQtdGB0Ywg0L/RgNC+0YbQtdGB0YHQvtGAINC/0YDQuCByZWxvYWQnZQ==?= In-Reply-To: <20190902115535.GO1877@mdounin.ru> References: <342fa0ac-f792-e639-0887-468322a59a36@gmail.com> <20190830124912.GE1877@mdounin.ru> <20190902115535.GO1877@mdounin.ru> Message-ID: <10e94ab6-b780-9a53-b161-dfcc672316fe@gmail.com> Спасибо большое за ответ. Потестил  с параметрами: ssl_session_tickets off; ssl_session_ticket_key /etc/nginx/ssl/ticket.key; И довольно интересно получилось: http://joxi.net/krD6q0jTKkV9R2.jpg На картинке числами отмечены reload'ы 1,2,6,7,10  - без настроек tickets (по умоланию включен) 3,4,5,8,9 - с отключенным tickets и файлом ssl_session_ticket_key. При этом всегда был включен кэш сессий:     ssl_session_cache   shared:SSL:20m;     ssl_session_timeout 30m; Пока сделал вывод, что с отключенным ssl_session_tickets средняя нагрузка выше, но при этом при reload'e нагрузка не так сильно возрастает по отношению к средней. Тесты не совсем чистые, постараюсь сделать более чистый эксперимент. On 02/09/2019 16:55, Maxim Dounin wrote: > Hello! > > On Sat, Aug 31, 2019 at 12:54:06PM +0500, Dmitry Sergeev wrote: > >> Добрый день! >> Спасибо за ответ. >> >> Конфиг полный, просто сократил количетсво виртуальных хостов, так как они одинаковые. > В конфиге значилось: > > include /etc/nginx/conf.d/*.conf; > include /etc/nginx/sites-enabled/*; > > Так что понять по нему, полный он, или нет - не представляется > возможным, отсюда и вопросы. > >> ssl_session_cache - действительно не настроено. >> ssl_dhparam - аналогично. >> сертификат один общий для всех, сгенерировал его для wildcard домена от let's encrypt (Signature Algorithm: sha256WithRSAEncryption, Public-Key: rsaEncryption (2048 bit)). >> >> Пытался оптимизировать ssl и посмотреть влияние его настроек на эту проблему. В частности пробовал глобально добавлять опции: >> >> *ssl_session_cache shared:SSL:20m;* >> *ssl_session_timeout 30m; *вроде никак не влияло, но я проверю еще раз конечно, и более чательно. > Если большая часть клиентов использует тикеты - то может и не > повлиять. Для теста можно попробовать отключить тикеты > (ssl_session_tickets) и/или настроить внешний ключ > (ssl_session_ticket_key), так как автоматически сгенерированные > ключи при reload'е обновляются. > >> Про ssl_dhparam не понял, с точки зрения производительности - >> его лучше добавлять но с небольшой битностью (2048 и меньше) или >> лучше совсем не использовать? > Лучше - не использовать. Даже 2048 для классического > Диффи-Хеллмана - это очень медленно. > -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Sep 2 17:11:11 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 2 Sep 2019 20:11:11 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC/0L7Qu9C90L7RgdGC0YzRjiDQt9Cw0LPRgNGD0LbQsNC10YIg?= =?UTF-8?B?0LLQtdGB0Ywg0L/RgNC+0YbQtdGB0YHQvtGAINC/0YDQuCByZWxvYWQnZQ==?= In-Reply-To: <10e94ab6-b780-9a53-b161-dfcc672316fe@gmail.com> References: <342fa0ac-f792-e639-0887-468322a59a36@gmail.com> <20190830124912.GE1877@mdounin.ru> <20190902115535.GO1877@mdounin.ru> <10e94ab6-b780-9a53-b161-dfcc672316fe@gmail.com> Message-ID: <20190902171111.GX1877@mdounin.ru> Hello! On Mon, Sep 02, 2019 at 08:54:51PM +0500, Dmitry Sergeev wrote: > Спасибо большое за ответ. > > Потестил  с параметрами: > > ssl_session_tickets off; > ssl_session_ticket_key /etc/nginx/ssl/ticket.key; Just in case, для работы такая конфигурация смысла не имеет - если тикеты выключены, то ключ для их шифрования не нужен. Ключ имеет смысл задавать, если тикеты включены. С точки зрения влияния на reload - внешний ключ позволит сохранить тикеты при reload'ах, а выключение тикетов - уведёт всё в кэш сессий. > И довольно интересно получилось: > http://joxi.net/krD6q0jTKkV9R2.jpg > > На картинке числами отмечены reload'ы > 1,2,6,7,10  - без настроек tickets (по умоланию включен) > 3,4,5,8,9 - с отключенным tickets и файлом ssl_session_ticket_key. > > При этом всегда был включен кэш сессий: > >     ssl_session_cache   shared:SSL:20m; >     ssl_session_timeout 30m; > > Пока сделал вывод, что с отключенным ssl_session_tickets средняя > нагрузка выше, но при этом при reload'e нагрузка не так сильно > возрастает по отношению к средней. Тесты не совсем чистые, постараюсь > сделать более чистый эксперимент. Ну выключать тикеты - это, безусловно, плохой путь. Тикеты - способ переложить хранение сессий на клиентов, и отказываться от этого - очевидно недальновидно с точки зрения нагрузки на сервер. А вот то, что средняя нагрузка без тикетов заметно выше - это немного странно. Само хранение сессий - должно бы стоить очень недорого с точки зрения процессора, а в остальном разница не принципиальна. Но, возможно, тут дело в том, что размер кэша SSL-сессий просто мал для имеющегося количества клиентов, и поэтому при выключении тикетов handshake'и начинают происходить чаще, что и приводит к росту потребления процессора. Отмечу также, что даже в наиболее экстремальных случаях из представленных на графике - рост потребления процессора с ~200% до ~300% не выглядит сколько-нибудь фатальным. Какой-то рост потребления процессора при релоадах - нормален, здесь же наблюдается рост всего в 1.5 раза. Если это проблема - то стоит задуматься о добавлении мощностей и/или заняться оптимизацией. -- Maxim Dounin http://mdounin.ru/ From balroga3 на yandex.ru Tue Sep 3 09:42:15 2019 From: balroga3 на yandex.ru (Pavel) Date: Tue, 3 Sep 2019 12:42:15 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0L/QuNGB0LDRgtGMINC60LvRjtGH0LggcHJlLW1hc3Rl?= =?UTF-8?B?ciDQvtGCIHRscy3RgdC+0LXQtNC40L3QtdC90LjQuSwg0L7QsdGA0LDQsdCw?= =?UTF-8?B?0YLRi9Cy0LDQtdC80YvRhSBuZ2lueD8=?= In-Reply-To: <1182867115.20190827235018@yandex.ru> References: <1182867115.20190827235018@yandex.ru> Message-ID: <1801394579.20190903124215@yandex.ru> Здравствуйте. > Hello! > > On Tue, Aug 27, 2019 at 11:50:18PM +0300, Pavel wrote: > >> Мы состоим в реестре организаторов распространения информации и >> поэтому обязаны предоставлять в надзорный орган ключи tls сессий. >> >> Для таких случаев существует механизм по перехвату вызовов библиотеки >> openssl: https://git.lekensteyn.nl/peter/wireshark-notes/tree/src/ >> Суть простая - перед запуском демона, обрабатывающего TLS-соединения >> клиентов, через LD_PRELOAD подгружается эта библиотека и она >> сбрасывает в текстовый файл, указанный в переменой SSLKEYLOGFILE, ключи pre-master. >> >> Эта схема срабатывает с апачем, но с энжинксом ключи не пишутся. Нет >> ли идей или подсказок из-за чего это может быть и как вообще можно записать >> эти самые pre-master keys в энжинксе? > > [...] > >> [Service] >> Environment=SSLKEYLOGFILE=/tmp/premaster.txt >> Environment=LD_PRELOAD=/usr/local/lib/libsslkeylog.so > > [...] > >> но тем не менее ключи в файл при обращении к энжинксу по https не >> пишутся. > > Скорее всего причина в том, что переменные > окружения очищаются при запуске, подробнее тут: > > http://nginx.org/r/env > Огромное спасибо! Ключи начали записываться когда добавил в nginx.conf env LD_PRELOAD=/usr/local/lib/libsslkeylog.so; env SSLKEYLOGFILE=/tmp/premaster.txt; From identw на gmail.com Tue Sep 3 10:18:36 2019 From: identw на gmail.com (Dmitry Sergeev) Date: Tue, 3 Sep 2019 15:18:36 +0500 Subject: =?UTF-8?B?UmU6IG5naW54INC/0L7Qu9C90L7RgdGC0YzRjiDQt9Cw0LPRgNGD0LbQsNC10YIg?= =?UTF-8?B?0LLQtdGB0Ywg0L/RgNC+0YbQtdGB0YHQvtGAINC/0YDQuCByZWxvYWQnZQ==?= In-Reply-To: <20190902171111.GX1877@mdounin.ru> References: <342fa0ac-f792-e639-0887-468322a59a36@gmail.com> <20190830124912.GE1877@mdounin.ru> <20190902115535.GO1877@mdounin.ru> <10e94ab6-b780-9a53-b161-dfcc672316fe@gmail.com> <20190902171111.GX1877@mdounin.ru> Message-ID: Добрый день,  спасибо за ответ. On 02/09/2019 22:11, Maxim Dounin wrote: > Just in case, для работы такая конфигурация смысла не имеет - если > тикеты выключены, то ключ для их шифрования не нужен. Ключ имеет > смысл задавать, если тикеты включены. > > С точки зрения влияния на reload - внешний ключ позволит сохранить > тикеты при reload'ах, а выключение тикетов - уведёт всё в кэш > сессий. > > Ну выключать тикеты - это, безусловно, плохой путь. Тикеты - > способ переложить хранение сессий на клиентов, и отказываться от > этого - очевидно недальновидно с точки зрения нагрузки на сервер. > Да, я неверно понял доки. > Отмечу также, что даже в наиболее экстремальных случаях из > представленных на графике - рост потребления процессора с ~200% до > ~300% не выглядит сколько-нибудь фатальным. Какой-то рост > потребления процессора при релоадах - нормален, здесь же > наблюдается рост всего в 1.5 раза. Если это проблема - то стоит > задуматься о добавлении мощностей и/или заняться оптимизацией Да, сейчас это для меня просто представляет интерес, после перехода на openssl 1.0.2g и включение http2, проблем это особых не вызывает. > А вот то, что средняя нагрузка без тикетов заметно выше - это > немного странно. Само хранение сессий - должно бы стоить очень > недорого с точки зрения процессора, а в остальном разница не > принципиальна. Но, возможно, тут дело в том, что размер кэша > SSL-сессий просто мал для имеющегося количества клиентов, и > поэтому при выключении тикетов handshake'и начинают происходить > чаще, что и приводит к росту потребления процессора. Возможно. Это немного не то, но мне было интересно как увеличение кэша ssl сессий повлияет на нагрузку при reload'e: http://dl4.joxi.net/drive/2019/09/03/0030/2608/1985072/72/8608b87db7.jpg Числами отметил разное количество ssl_session_cache от 20m до 256m. Вроде никак не влияет.  Сегодня тестил при 8K rps (вчера 5-6K). Поэтому нагрузка скачет чуть выше. А вот тикеты помогли вообще круто.  Нагрузка поднимается всего-лишь на 5%-10%: http://dl3.joxi.net/drive/2019/09/03/0030/2608/1985072/72/ac00a4d2d0.jpg Здесь 1 - это без ssl_session_ticket_key, а 2,3,4 - c включенными тикетами и указанными постояным ключем ssl_session_ticket_key. Итого: Сущесвтенно решить проблему помогло следующее: 1) переход на http2 (openssl 1.02.g) - понизилась нагрузка в целом, и при reload'e нагрузка конечно возрастала, но не надолго (5-20 секунд, а раньше от 30-40 секунд, до 5 минут). 2) И вообще убрать хоть какое-то сущесвтенное повышение нагрзуки помогло включение ssl_session_tickets(по умолчанию включено) с установелнным ssl_session_ticket_key (по умолчанию генерируется заново при каждом reload'e, его лучше указать чтобы этого не происходило). Оставил такие параметры:     ssl_session_cache   shared:SSL:20m;     ssl_session_timeout 30m;     ssl_session_tickets on;     ssl_session_ticket_key /etc/nginx/ssl/ticket.key; # ticket.key - файл с рандомными 80 или 48 байт Кэш ssl сессий оставил, хоть в моем случае он вроде как сильно не влияет (по крайней мере я этого не заметил). Спасибо Вам большое, Ваши советы помогли полностью избавиться от этого эффекта. Надеюсь кому-то тоже будет полезна эта переписка. -- Kind regards Dmitry Sergeev Tel: +7 (951) 129-75-72 From mdounin на mdounin.ru Tue Sep 3 15:42:48 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 3 Sep 2019 18:42:48 +0300 Subject: =?UTF-8?B?UmU6IG5naW54INC/0L7Qu9C90L7RgdGC0YzRjiDQt9Cw0LPRgNGD0LbQsNC10YIg?= =?UTF-8?B?0LLQtdGB0Ywg0L/RgNC+0YbQtdGB0YHQvtGAINC/0YDQuCByZWxvYWQnZQ==?= In-Reply-To: References: <342fa0ac-f792-e639-0887-468322a59a36@gmail.com> <20190830124912.GE1877@mdounin.ru> <20190902115535.GO1877@mdounin.ru> <10e94ab6-b780-9a53-b161-dfcc672316fe@gmail.com> <20190902171111.GX1877@mdounin.ru> Message-ID: <20190903154248.GC1877@mdounin.ru> Hello! On Tue, Sep 03, 2019 at 03:18:36PM +0500, Dmitry Sergeev wrote: > Добрый день,  спасибо за ответ. > > On 02/09/2019 22:11, Maxim Dounin wrote: > > Just in case, для работы такая конфигурация смысла не имеет - если > > тикеты выключены, то ключ для их шифрования не нужен. Ключ имеет > > смысл задавать, если тикеты включены. > > > > С точки зрения влияния на reload - внешний ключ позволит сохранить > > тикеты при reload'ах, а выключение тикетов - уведёт всё в кэш > > сессий. > > > > Ну выключать тикеты - это, безусловно, плохой путь. Тикеты - > > способ переложить хранение сессий на клиентов, и отказываться от > > этого - очевидно недальновидно с точки зрения нагрузки на сервер. > > > Да, я неверно понял доки. > > > Отмечу также, что даже в наиболее экстремальных случаях из > > представленных на графике - рост потребления процессора с ~200% до > > ~300% не выглядит сколько-нибудь фатальным. Какой-то рост > > потребления процессора при релоадах - нормален, здесь же > > наблюдается рост всего в 1.5 раза. Если это проблема - то стоит > > задуматься о добавлении мощностей и/или заняться оптимизацией > Да, сейчас это для меня просто представляет интерес, после перехода на > openssl 1.0.2g и включение http2, проблем это особых не вызывает. > > А вот то, что средняя нагрузка без тикетов заметно выше - это > > немного странно. Само хранение сессий - должно бы стоить очень > > недорого с точки зрения процессора, а в остальном разница не > > принципиальна. Но, возможно, тут дело в том, что размер кэша > > SSL-сессий просто мал для имеющегося количества клиентов, и > > поэтому при выключении тикетов handshake'и начинают происходить > > чаще, что и приводит к росту потребления процессора. > Возможно. Это немного не то, но мне было интересно как увеличение кэша > ssl сессий повлияет на нагрузку при reload'e: > > http://dl4.joxi.net/drive/2019/09/03/0030/2608/1985072/72/8608b87db7.jpg > > Числами отметил разное количество ssl_session_cache от 20m до 256m. > Вроде никак не влияет.  Сегодня тестил при 8K rps (вчера 5-6K). Поэтому > нагрузка скачет чуть выше. От размера кэша сессий должна зависеть высота "полки" между reload'ами. Если кэш мал - то полных handshake'ов будет больше, чем могло бы быть, и соответственно CPU usage в полке будет больше. Ну и всё это имеет смысл скорее при выключенных тикетах, о чём и шла речь выше. А на графике - они, похоже, включены. > А вот тикеты помогли вообще круто.  Нагрузка поднимается всего-лишь на > 5%-10%: > http://dl3.joxi.net/drive/2019/09/03/0030/2608/1985072/72/ac00a4d2d0.jpg > > Здесь 1 - это без ssl_session_ticket_key, а 2,3,4 - c включенными > тикетами и указанными постояным ключем ssl_session_ticket_key. Ну ок, то есть как и ожидалось - пик явно из-за SSL handshake'ов, использование постоянных ключей для тикетов - лечит. > Итого: > > Сущесвтенно решить проблему помогло следующее: > 1) переход на http2 (openssl 1.02.g) - понизилась нагрузка в целом, и > при reload'e нагрузка конечно возрастала, но не надолго (5-20 секунд, а > раньше от 30-40 секунд, до 5 минут). > 2) И вообще убрать хоть какое-то сущесвтенное повышение нагрзуки помогло > включение ssl_session_tickets(по умолчанию включено) с установелнным > ssl_session_ticket_key (по умолчанию генерируется заново при каждом > reload'e, его лучше указать чтобы этого не происходило). > > Оставил такие параметры: > >     ssl_session_cache   shared:SSL:20m; >     ssl_session_timeout 30m; >     ssl_session_tickets on; >     ssl_session_ticket_key /etc/nginx/ssl/ticket.key; # ticket.key - > файл с рандомными 80 или 48 байт > > Кэш ssl сессий оставил, хоть в моем случае он вроде как сильно не влияет > (по крайней мере я этого не заметил). Использовать "ssl_session_tickets on;" - не нужно, это поведение по умолчанию. И отмечу также, что ключ для тикетов - надо периодически менять, ибо получив этот ключ - можно расшифровать весь трафик. И я бы ещё рекомендовал посмотреть в сторону ECDSA-сертификатов, там handshake банально на порядок быстрее при той же криптостойкости: $ openssl speed rsa2048 ecdsap256 ... sign verify sign/s verify/s rsa 2048 bits 0.000992s 0.000033s 1008.1 30297.9 sign verify sign/s verify/s 256 bit ecdsa (nistp256) 0.0001s 0.0001s 17145.0 9276.9 То есть 1008.1 подписей в секунду в случае RSA 2048 bit, и 17145.0 подписей в секунду для ECDSA 256 bit. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue Sep 3 22:48:03 2019 From: nginx-forum на forum.nginx.org (analytic) Date: Tue, 03 Sep 2019 18:48:03 -0400 Subject: =?UTF-8?B?UmU6IE5naW54INC90LUg0LTQvtCx0LDQstC70Y/QtdGCINC90LXQvtCx0YXQvtC0?= =?UTF-8?B?0LjQvNGL0LUg0LHQuNCx0LvQuNC+0YLQtdC60Lgg0L/RgNC4INGB0LHQvtGA?= =?UTF-8?B?0LrQtSDQuNC3INC40YHRhdC+0LTQvdC40LrQvtCyINGB0L4g0YHRgtC+0YA=?= =?UTF-8?B?0L7QvdC90LjQvNC4INC80L7QtNGD0Y/QvNC40Lg=?= In-Reply-To: References: Message-ID: <3487449f284edfaad0d74b826bbe5711.NginxMailingListRussian@forum.nginx.org> Спасибо. Классный мастер класс, жаль я раньше о нем не знал :(( Сберег бы время. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285435,285540#msg-285540 From nginx-forum на forum.nginx.org Wed Sep 4 01:21:00 2019 From: nginx-forum на forum.nginx.org (pavlusha23) Date: Tue, 03 Sep 2019 21:21:00 -0400 Subject: =?UTF-8?B?bmd4IGh0dHAgY2hhcnNldCBtb2R1bGUg0L3QtSDQtNC+0LHQsNCy0LvRj9C10YIg?= =?UTF-8?B?0L/RgNC+0LHQtdC7INC00LvRjyB0ZXh0L3BsYWlu?= Message-ID: <05af4755a6a4b4de12a61566839a24ac.NginxMailingListRussian@forum.nginx.org> Не могу понять почему nginx формирует разные заголовки. Баг? Конфиг такой: include /etc/nginx/mime.types; charset "utf-8"; charset_types text/xml text/plain application/javascript application/rss+xml application/xml text/css text/javascript text/markdown text/calendar text/x-component text/vcard text/cache-manifest text/vtt application/json application/manifest+json; default_type application/octet-stream; При отправке в PHP заголовка : header('Content-type: text/plain'); echo "test"; В браузере(в любом) по ssl HTTP 2 получаю: text/plain;charset=UTF-8 т.е. перед charset= нет пробела. Мелочь, но хотелось бы одинакового поведения для всех заголовков. Для других типов такого не наблюдаю, там всё в норме, например в том же PHP nginx выдаёт: content-type: application/xml; charset=utf-8 Хотя всё конечно не проверял, возможно глючит еще на каких-то заголовках. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285541,285541#msg-285541 From nginx-forum на forum.nginx.org Fri Sep 6 05:05:21 2019 From: nginx-forum на forum.nginx.org (rambabuy) Date: Fri, 06 Sep 2019 01:05:21 -0400 Subject: how can I use keep alive idle connections for GET requests and new connections to POST requests Message-ID: <0defd66c69b79429a84ec555cd893314.NginxMailingListRussian@forum.nginx.org> Hi, To avoid some Issues I need to create new connections for POST (upload file) requests. But, If I disable keepalive under upstream I am getting the following error " 99: Cannot assign requested address) while connecting to upstream, " Is there a possibility to use idle connections for GET requests and new connection for POSTS requests? or is there a way to control TCP new connections or to control TIME_WAIT connections. TIME_WAIT connections causes "99: Cannot assign requested address) while connecting to upstream, " error Thanks Rambabu Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285571,285571#msg-285571 From actionmanager на gmail.com Mon Sep 9 15:55:46 2019 From: actionmanager на gmail.com (actionmanager на gmail.com) Date: Mon, 9 Sep 2019 18:55:46 +0300 Subject: =?UTF-8?B?0J7RiNC40LHQutCwINC/0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC90LjQuCA=?= =?UTF-8?B?0L/QtdGA0LXQvNC10L3QvdGL0YUg0LIgc3NsX2NlcnRpZmljYXRlINC4IHNz?= =?UTF-8?B?bF9jZXJ0aWZpY2F0ZV9rZXk=?= In-Reply-To: References: <2145153.Qye9C7YK05@vbart-laptop> Message-ID: <10410707398.20190909185546@gmail.com> ubuntu 18.04 nginx/1.17.3 nginx не может считать файл fullchain.cer при использовании переменной в директиве ssl_certificate. ssl_certificate /root/.acme.sh/$ssl_key_name/fullchain.cer; 2019/09/09 15:30:46 [error] 15246#15246: *546 cannot load certificate "/root/.acme.sh/site.org/fullchain.cer": BIO_new_file() failed (SSL: error:0200100D:system library:fopen:Permission denied:fopen('/root/.acme.sh/site.org/fullchain.cer','r') error:2006D002:BIO routines:BIO_new_file:system lib) while SSL handshaking прописываю путь без переменной, всё работает. видимо при запуске nginx читает от root , а при использовании переменных в ssl_certificate от пользователя из конфига ( www-data ) т.к. путь формируется динамически. From mdounin на mdounin.ru Mon Sep 9 16:07:13 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 9 Sep 2019 19:07:13 +0300 Subject: =?UTF-8?B?UmU6INCe0YjQuNCx0LrQsCDQv9GA0Lgg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC4?= =?UTF-8?B?0Lgg0L/QtdGA0LXQvNC10L3QvdGL0YUg0LIgc3NsX2NlcnRpZmljYXRlINC4?= =?UTF-8?B?IHNzbF9jZXJ0aWZpY2F0ZV9rZXk=?= In-Reply-To: <10410707398.20190909185546@gmail.com> References: <2145153.Qye9C7YK05@vbart-laptop> <10410707398.20190909185546@gmail.com> Message-ID: <20190909160713.GP1877@mdounin.ru> Hello! On Mon, Sep 09, 2019 at 06:55:46PM +0300, actionmanager на gmail.com wrote: > ubuntu 18.04 > > nginx/1.17.3 > > nginx не может считать файл fullchain.cer при использовании переменной в директиве ssl_certificate. > > ssl_certificate /root/.acme.sh/$ssl_key_name/fullchain.cer; > > > 2019/09/09 15:30:46 [error] 15246#15246: *546 cannot load certificate > "/root/.acme.sh/site.org/fullchain.cer": BIO_new_file() failed (SSL: error:0200100D:system library:fopen:Permission denied:fopen('/root/.acme.sh/site.org/fullchain.cer','r') error:2006D002:BIO routines:BIO_new_file:system lib) while SSL handshaking > > > прописываю путь без переменной, всё работает. > > видимо при запуске nginx читает от root , а при использовании > переменных в ssl_certificate от пользователя из конфига ( www-data ) > т.к. путь формируется динамически. Да, именно так. Рабочие процессы в норме работают не от рута, и чтобы они могли читать сертификаты - сертификаты и ключи должны быть доступны рабочим процессам на чтение. Необходимость давать рабочим процессам право на чтение ключей - одна из причин, почему использовать динамическую загрузку сертификатов без нужды - не стоит. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Fri Sep 20 09:01:06 2019 From: nginx-forum на forum.nginx.org (darksmoke) Date: Fri, 20 Sep 2019 05:01:06 -0400 Subject: =?UTF-8?B?0J7RgtCy0LXRgiDQsiDQt9Cw0LLQuNGB0LjQvNC+0YHRgtC4INC+0YIg0L/QtdGA?= =?UTF-8?B?0LXQtNCw0L3QvdC+0LPQviDQv9Cw0YDQsNC80LXRgtGA0LAu?= Message-ID: <2de5f4cec86be71d7f21e478f43d6ab0.NginxMailingListRussian@forum.nginx.org> Добрый день подскажите, пожалуйста как такое можно реализовать. Есть GET запрос, в нем передается параметр, varID=car Вопрос: Как в зависимости от того что пришло в varID вернуть разный ответ if ($arg_varID !~* ("car"|"moto") ) { Вернуть JSON } else { root $root_path/modules; } Т.е. если НЕ car или Не moto, то вернуть JSON. А если совпало, то загрузить статику Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285655,285655#msg-285655 From mdounin на mdounin.ru Fri Sep 20 13:22:49 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 20 Sep 2019 16:22:49 +0300 Subject: =?UTF-8?B?UmU6INCe0YLQstC10YIg0LIg0LfQsNCy0LjRgdC40LzQvtGB0YLQuCDQvtGCINC/?= =?UTF-8?B?0LXRgNC10LTQsNC90L3QvtCz0L4g0L/QsNGA0LDQvNC10YLRgNCwLg==?= In-Reply-To: <2de5f4cec86be71d7f21e478f43d6ab0.NginxMailingListRussian@forum.nginx.org> References: <2de5f4cec86be71d7f21e478f43d6ab0.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190920132249.GI1877@mdounin.ru> Hello! On Fri, Sep 20, 2019 at 05:01:06AM -0400, darksmoke wrote: > Добрый день > подскажите, пожалуйста как такое можно реализовать. > Есть GET запрос, в нем передается параметр, varID=car > > Вопрос: > Как в зависимости от того что пришло в varID вернуть разный ответ > > > if ($arg_varID !~* ("car"|"moto") ) { > Вернуть JSON > } > else > { > root $root_path/modules; > } > > Т.е. если НЕ car или Не moto, то вернуть JSON. А если совпало, то загрузить > статику Вариантов масса. Например, можно сделать ровно то, что у вас написано, с точностью до правильно составленного регулярного выражения: if ($arg_varid ~ "^(?!car$|moto$).*$") { return 200 '{ "json": 1 }'; } То, что внутрь if'а не попадёт - будет обработано обработчиком по умолчанию, то есть как статика. Директиву root можно задать в любом месте (вот только не надо в неё совать переменные без нужды). Или же можно воспользоваться инструкцией break для окончания обработки инструкций модуля rewrite: if ($arg_varid = "car") { break; } if ($arg_varid = "moto") { break; } return 200 '{ "json": 1 }'; Так как дальнейшая обработка инстураций rewrite-модуля после break прекращается, то return сработает только если $arg_varid не "car" и не "moto". Если возможных значений может быть много, то эффективнее всего сделать map, с помощью которого получить готовое условие для проверки: map $arg_varid $need_json { default 1; car 0; moto 0; } if ($need_json) { return 200 '{ "json": 1 }'; } Подробнее в документации тут: http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html#if http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html#return http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html#break http://nginx.org/ru/docs/http/ngx_http_map_module.html -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Mon Sep 23 17:09:03 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Mon, 23 Sep 2019 13:09:03 -0400 Subject: cache file has too long header Message-ID: Эта ошибка часто в логе для разных файлов. В гугле нашел что это решается увеличением proxy_buffer_size, но он и так у нас 8k. Подскажите как решить. Версия 1.16.1, OS FreeBSD 11.3. Из-за этой ошибки кеш игнорируется и ресурс запрашивается из апстрима, а это дорогой контент (google maps). Проблема только с этими ресурсами, другие кешируются нормально. Урл не такой уж и длинный, вроде. Пример ошибки: 2019/09/23 21:04:01 [crit] 95594#100948: *426913488 cache file "/usr/home/nginx/cache/myproj/maps/d/2d/28889e499a0f9ef187ba9fb63270c2dd" has too long header, client: 172.16.1.16, server: assets.example.com, request: "GET /maps/api/staticmap?key=AIzaSyBsXrvwBUBTrAMP0K-uCSJaH2cKU4xLPu4&markers=12.412358%2C53.823786&size=320x100&zoom=11 HTTP/1.1", host: "assets.example.com", referrer: "https://example.com/foo/bar". proxy_temp_path /usr/home/nginx/temp; proxy_http_version 1.1; proxy_headers_hash_max_size 1024; proxy_headers_hash_bucket_size 128; proxy_buffer_size 8k; proxy_connect_timeout 15s; proxy_send_timeout 5s; proxy_cache_path /usr/home/nginx/cache/myproj/maps levels=1:2 keys_zone=myproj-maps:128m inactive=30d max_size=8g; Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285677#msg-285677 From pluknet на nginx.com Tue Sep 24 09:26:23 2019 From: pluknet на nginx.com (Sergey Kandaurov) Date: Tue, 24 Sep 2019 12:26:23 +0300 Subject: cache file has too long header In-Reply-To: References: Message-ID: <5FE563C4-E972-47A2-A4AC-3395C98E955E@nginx.com> > On 23 Sep 2019, at 20:09, rihad wrote: > > Эта ошибка часто в логе для разных файлов. В гугле нашел что это решается > увеличением proxy_buffer_size, но он и так у нас 8k. > Подскажите как решить. Версия 1.16.1, OS FreeBSD 11.3. Из-за этой ошибки кеш > игнорируется и ресурс запрашивается из апстрима, а это дорогой контент > (google maps). Проблема только с этими ресурсами, другие кешируются > нормально. Урл не такой уж и длинный, вроде. > > Пример ошибки: > 2019/09/23 21:04:01 [crit] 95594#100948: *426913488 cache file > "/usr/home/nginx/cache/myproj/maps/d/2d/28889e499a0f9ef187ba9fb63270c2dd" > has too long header, client: 172.16.1.16, server: assets.example.com, > request: "GET > /maps/api/staticmap?key=AIzaSyBsXrvwBUBTrAMP0K-uCSJaH2cKU4xLPu4&markers=12.412358%2C53.823786&size=320x100&zoom=11 > HTTP/1.1", host: "assets.example.com", referrer: > "https://example.com/foo/bar". Сходил на вышеупомянутый ресурс, увидел в заголовке ответа: vary: Accept-Language Попробуйте этот патч (Node ID f727ed0e9f2f3e4706fa6444e8e3df0a21f8fa3a): http://mailman.nginx.org/pipermail/nginx-devel/2018-January/010774.html -- Sergey Kandaurov From nginx-forum на forum.nginx.org Tue Sep 24 09:31:22 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Tue, 24 Sep 2019 05:31:22 -0400 Subject: cache file has too long header In-Reply-To: <5FE563C4-E972-47A2-A4AC-3395C98E955E@nginx.com> References: <5FE563C4-E972-47A2-A4AC-3395C98E955E@nginx.com> Message-ID: Спасибо, а чего оно за полтора года не перекочевало из devel в mainline? У нас кеш 3 уровней, поддерживать патч на каждом из них как-то не то. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285681#msg-285681 From pluknet на nginx.com Tue Sep 24 09:47:42 2019 From: pluknet на nginx.com (Sergey Kandaurov) Date: Tue, 24 Sep 2019 12:47:42 +0300 Subject: cache file has too long header In-Reply-To: References: <5FE563C4-E972-47A2-A4AC-3395C98E955E@nginx.com> Message-ID: > On 24 Sep 2019, at 12:31, rihad wrote: > > Спасибо, а чего оно за полтора года не перекочевало из devel в mainline? У > нас кеш 3 уровней, поддерживать патч на каждом из них как-то не то. Из-за недостатка (отсутствия) тестирования на реальных кейсах. AFAIK, пока что никто из ушедших с патчем, не вернулся, чтобы сообщить, помогает он или нет. -- Sergey Kandaurov From nginx-forum на forum.nginx.org Tue Sep 24 13:11:38 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Tue, 24 Sep 2019 09:11:38 -0400 Subject: cache file has too long header In-Reply-To: <5FE563C4-E972-47A2-A4AC-3395C98E955E@nginx.com> References: <5FE563C4-E972-47A2-A4AC-3395C98E955E@nginx.com> Message-ID: А это не повлияет на другие ресурсы, кроме maps? Например если будет закеширован контент, отличающийся по языку, он правильно будет отдан? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285686#msg-285686 From pluknet на nginx.com Tue Sep 24 13:55:09 2019 From: pluknet на nginx.com (Sergey Kandaurov) Date: Tue, 24 Sep 2019 16:55:09 +0300 Subject: cache file has too long header In-Reply-To: References: <5FE563C4-E972-47A2-A4AC-3395C98E955E@nginx.com> Message-ID: > On 24 Sep 2019, at 16:11, rihad wrote: > > А это не повлияет на другие ресурсы, кроме maps? Например если будет > закеширован контент, отличающийся по языку, он правильно будет отдан? > Каким образом? С патчем nginx перестанет проксировать в upstream по secondary key, отдавая вместо этого из холодного кеша. Больше ничего не меняется. -- Sergey Kandaurov From nginx-forum на forum.nginx.org Tue Sep 24 14:35:01 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Tue, 24 Sep 2019 10:35:01 -0400 Subject: cache file has too long header In-Reply-To: References: <5FE563C4-E972-47A2-A4AC-3395C98E955E@nginx.com> Message-ID: <9ae5a3923d04b6bb2e12de22af327b38.NginxMailingListRussian@forum.nginx.org> Пропатчил, построил, перезапустил через роллинг апгрейд (USR+QUIT). Я так понимаю изменение для новых файлов будет актуально т.к. хедер поменялся. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285690#msg-285690 From nginx-forum на forum.nginx.org Tue Sep 24 14:37:34 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Tue, 24 Sep 2019 10:37:34 -0400 Subject: cache file has too long header In-Reply-To: <9ae5a3923d04b6bb2e12de22af327b38.NginxMailingListRussian@forum.nginx.org> References: <5FE563C4-E972-47A2-A4AC-3395C98E955E@nginx.com> <9ae5a3923d04b6bb2e12de22af327b38.NginxMailingListRussian@forum.nginx.org> Message-ID: <34eb510fc58173ba7d8d33771a7413fc.NginxMailingListRussian@forum.nginx.org> Что любопытно после релоада нет ни одной ошибки, хотя раньше хотя бы раз в минуту было. Наверное пока cache loader запущен этих ситуаций не возникает. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285691#msg-285691 From nginx-forum на forum.nginx.org Tue Sep 24 14:56:14 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Tue, 24 Sep 2019 10:56:14 -0400 Subject: cache file has too long header In-Reply-To: <34eb510fc58173ba7d8d33771a7413fc.NginxMailingListRussian@forum.nginx.org> References: <5FE563C4-E972-47A2-A4AC-3395C98E955E@nginx.com> <9ae5a3923d04b6bb2e12de22af327b38.NginxMailingListRussian@forum.nginx.org> <34eb510fc58173ba7d8d33771a7413fc.NginxMailingListRussian@forum.nginx.org> Message-ID: <343566a206797213f6572267d127151d.NginxMailingListRussian@forum.nginx.org> cache loader давно вышел, новых записей "too long header" в логе пока нет. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285692#msg-285692 From mdounin на mdounin.ru Tue Sep 24 15:17:03 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 24 Sep 2019 18:17:03 +0300 Subject: nginx-1.17.4 Message-ID: <20190924151703.GV1877@mdounin.ru> Изменения в nginx 1.17.4 24.09.2019 *) Изменение: улучшено детектирование некорректного поведения клиентов в HTTP/2. *) Изменение: в обработке непрочитанного тела запроса при возврате ошибок в HTTP/2. *) Исправление: директива worker_shutdown_timeout могла не работать при использовании HTTP/2. *) Исправление: при использовании HTTP/2 и директивы proxy_request_buffering в рабочем процессе мог произойти segmentation fault. *) Исправление: на Windows при использовании SSL уровень записи в лог ошибки ECONNABORTED был "crit" вместо "error". *) Исправление: nginx игнорировал лишние данные при использовании chunked transfer encoding. *) Исправление: если использовалась директива return и при чтении тела запроса возникала ошибка, nginx всегда возвращал ошибку 500. *) Исправление: в обработке ошибок выделения памяти. -- Maxim Dounin http://nginx.org/ From drybalka на docdoc.ru Wed Sep 25 12:19:55 2019 From: drybalka на docdoc.ru (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0KDRi9Cx0LDQu9C60LA=?=) Date: Wed, 25 Sep 2019 14:19:55 +0200 Subject: =?UTF-8?B?0JLRgNC10LzRjyBzc2wgaGFuZHNoYWtlIFJTQSAmIEVDRFNB?= Message-ID: Добрый день, прошу помочь разобраться с проблемой: Nginx 1.16.1 (проблема была и на прошлых версиях) из оф репозитория nginx для debian, openssl 1.1.1c (проблема есть и на openssl 1.1.0) Прописываю два ключа RSA & *ECDSA*. Пробовал ключи как от LE так и от comoda Пример настроек: > ssl_session_cache shared:SSL:5m; > ssl_session_timeout 30m; > ssl_ecdh_curve X25519:prime256v1; > ssl_buffer_size 4k; > ssl_session_tickets off; > resolver 8.8.8.8 8.8.4.4 valid=5m; #ipv6=off > resolver_timeout 1s; > ssl_prefer_server_ciphers on; > ssl_protocols TLSv1.2 TLSv1.3; > ssl_ciphers > 'TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384'; > ssl_stapling on; - включал выключал, разницы нет. Время хендшейка около 40мс. Если оставить только RSA то время уменьшается до 10мс Если оставить только EDSA, то время незначительно меняется и равно 38-39мс Если проверять скорость подписей openssl то ECDSA реально быстрее RSA, но почему при https подключении этого не видно? Проверял как чистым curl, так и black box экспортером для отслеживания динамики. Прошу помочь разобраться с данным нюансом ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Sep 25 13:27:00 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 25 Sep 2019 16:27:00 +0300 Subject: =?UTF-8?B?UmU6INCS0YDQtdC80Y8gc3NsIGhhbmRzaGFrZSBSU0EgJiBFQ0RTQQ==?= In-Reply-To: References: Message-ID: <20190925132700.GB1877@mdounin.ru> Hello! On Wed, Sep 25, 2019 at 02:19:55PM +0200, Дмитрий Рыбалка wrote: > Добрый день, прошу помочь разобраться с проблемой: > Nginx 1.16.1 (проблема была и на прошлых версиях) из оф репозитория nginx > для debian, openssl 1.1.1c (проблема есть и на openssl 1.1.0) > Прописываю два ключа RSA & *ECDSA*. Пробовал ключи как от LE так и от comoda > > Пример настроек: > > > ssl_session_cache shared:SSL:5m; > > ssl_session_timeout 30m; > > ssl_ecdh_curve X25519:prime256v1; > > ssl_buffer_size 4k; > > ssl_session_tickets off; > > resolver 8.8.8.8 8.8.4.4 valid=5m; #ipv6=off > > resolver_timeout 1s; > > ssl_prefer_server_ciphers on; > > ssl_protocols TLSv1.2 TLSv1.3; > > ssl_ciphers > > 'TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384'; > > ssl_stapling on; - включал выключал, разницы нет. > > > > Время хендшейка около 40мс. > Если оставить только RSA то время уменьшается до 10мс > Если оставить только EDSA, то время незначительно меняется и равно 38-39мс > Если проверять скорость подписей openssl то ECDSA реально быстрее RSA, но > почему при https подключении этого не видно? > Проверял как чистым curl, так и black box экспортером для отслеживания > динамики. > Прошу помочь разобраться с данным нюансом Начать стоит с вопроса как именно и где вы измеряете время (и зачем). Если время измерять на клиенте - то ECDSA медленнее RSA, такак операция проверки подписи в ECDSA сильно дороже. Скажем, для ECDSA P-256 и RSA 2048 ситуация выглядит так: $ openssl speed rsa2048 ecdsap256 ... sign verify sign/s verify/s rsa 2048 bits 0.005821s 0.000168s 171.8 5958.5 sign verify sign/s verify/s 256 bit ecdsa (nistp256) 0.0003s 0.0012s 3588.2 858.3 То есть операция проверки подписи для ECDSA в разы дороже, чем для RSA. Соответственно если измерять время handshake'а между ничего не делающим быстрым сервером и клиентом фиксированной и не очень большой производительности - от ECDSA-сертификатов будет сплошной вред, ибо на него ляжет на порядок больше вычислительной работы. Основная польза от ECDSA-сертификатов - это существенно меньшая нагрузка на сервер, и соответственно возможность обслуживать существенно большее количество клиентов. Но её в таком тесте просто не будет видно. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Sep 25 14:03:09 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Wed, 25 Sep 2019 10:03:09 -0400 Subject: cache file has too long header In-Reply-To: References: Message-ID: <92d10cb229bbec84e29475c3ec776a02.NginxMailingListRussian@forum.nginx.org> Ни одной записи за сутки! Вот вам фидбяк ) Спасибо. Надеюсь патч появится в релизах. Для его проявления не нужно каких-то крупных деплоев, если я правильно понял, а только чтобы апстрим возвращал нгинксу Vary для кешируемого ресурса. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285677,285705#msg-285705 From drybalka на docdoc.ru Wed Sep 25 14:46:21 2019 From: drybalka на docdoc.ru (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0KDRi9Cx0LDQu9C60LA=?=) Date: Wed, 25 Sep 2019 07:46:21 -0700 Subject: =?UTF-8?B?UmU6INCS0YDQtdC80Y8gc3NsIGhhbmRzaGFrZSBSU0EgJiBFQ0RTQQ==?= In-Reply-To: <20190925132700.GB1877@mdounin.ru> References: <20190925132700.GB1877@mdounin.ru> Message-ID: Благодарю, я изначально неверно понял и решил что на стороне клиента также будет уменьшение времени. Еще раз Спасибо. On 25 September 2019 at 15:27:09, Maxim Dounin (mdounin на mdounin.ru) wrote: Hello! On Wed, Sep 25, 2019 at 02:19:55PM +0200, Дмитрий Рыбалка wrote: > Добрый день, прошу помочь разобраться с проблемой: > Nginx 1.16.1 (проблема была и на прошлых версиях) из оф репозитория nginx > для debian, openssl 1.1.1c (проблема есть и на openssl 1.1.0) > Прописываю два ключа RSA & *ECDSA*. Пробовал ключи как от LE так и от comoda > > Пример настроек: > > > ssl_session_cache shared:SSL:5m; > > ssl_session_timeout 30m; > > ssl_ecdh_curve X25519:prime256v1; > > ssl_buffer_size 4k; > > ssl_session_tickets off; > > resolver 8.8.8.8 8.8.4.4 valid=5m; #ipv6=off > > resolver_timeout 1s; > > ssl_prefer_server_ciphers on; > > ssl_protocols TLSv1.2 TLSv1.3; > > ssl_ciphers > > 'TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384'; > > ssl_stapling on; - включал выключал, разницы нет. > > > > Время хендшейка около 40мс. > Если оставить только RSA то время уменьшается до 10мс > Если оставить только EDSA, то время незначительно меняется и равно 38-39мс > Если проверять скорость подписей openssl то ECDSA реально быстрее RSA, но > почему при https подключении этого не видно? > Проверял как чистым curl, так и black box экспортером для отслеживания > динамики. > Прошу помочь разобраться с данным нюансом Начать стоит с вопроса как именно и где вы измеряете время (и зачем). Если время измерять на клиенте - то ECDSA медленнее RSA, такак операция проверки подписи в ECDSA сильно дороже. Скажем, для ECDSA P-256 и RSA 2048 ситуация выглядит так: $ openssl speed rsa2048 ecdsap256 ... sign verify sign/s verify/s rsa 2048 bits 0.005821s 0.000168s 171.8 5958.5 sign verify sign/s verify/s 256 bit ecdsa (nistp256) 0.0003s 0.0012s 3588.2 858.3 То есть операция проверки подписи для ECDSA в разы дороже, чем для RSA. Соответственно если измерять время handshake'а между ничего не делающим быстрым сервером и клиентом фиксированной и не очень большой производительности - от ECDSA-сертификатов будет сплошной вред, ибо на него ляжет на порядок больше вычислительной работы. Основная польза от ECDSA-сертификатов - это существенно меньшая нагрузка на сервер, и соответственно возможность обслуживать существенно большее количество клиентов. Но её в таком тесте просто не будет видно. -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx-ru mailing list nginx-ru на nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu Sep 26 10:06:54 2019 From: nginx-forum на forum.nginx.org (classic85) Date: Thu, 26 Sep 2019 06:06:54 -0400 Subject: nginx http_x_forwarded_for blocking ip Message-ID: <2b4506983cf236c39c587688be8b444f.NginxMailingListRussian@forum.nginx.org> всем привет подкажите плиз нужно блокировать ip по заголовку: http_x_forward_for":«10.13.2.14, 10.99.111.25:13555 нужно блокировать только если эти два ip вместе приходят пробовал разные способы. все равно проходит пример if ($http_x_forward_for ~ " ?10\.13\.2\.14*") { return 403; Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285707,285707#msg-285707 From chipitsine на gmail.com Thu Sep 26 10:30:28 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 26 Sep 2019 15:30:28 +0500 Subject: nginx http_x_forwarded_for blocking ip In-Reply-To: <2b4506983cf236c39c587688be8b444f.NginxMailingListRussian@forum.nginx.org> References: <2b4506983cf236c39c587688be8b444f.NginxMailingListRussian@forum.nginx.org> Message-ID: map пробовали ? если хочется вхождения в разном порядке (слева направо и справа налево), можно два map, сначала по одному вхождению, потом каскадом по второму чт, 26 сент. 2019 г. в 15:07, classic85 : > всем привет > > подкажите плиз > нужно блокировать ip по заголовку: > http_x_forward_for":«10.13.2.14, 10.99.111.25:13555 > нужно блокировать только если эти два ip вместе приходят > пробовал разные способы. все равно проходит > > пример > > if ($http_x_forward_for ~ " ?10\.13\.2\.14*") { > return 403; > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,285707,285707#msg-285707 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Thu Sep 26 10:49:12 2019 From: nginx-forum на forum.nginx.org (classic85) Date: Thu, 26 Sep 2019 06:49:12 -0400 Subject: nginx http_x_forwarded_for blocking ip In-Reply-To: References: Message-ID: а можно пример? пожалуйста слева направо да Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285707,285711#msg-285711 From bgx на protva.ru Thu Sep 26 10:58:19 2019 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Thu, 26 Sep 2019 13:58:19 +0300 Subject: nginx http_x_forwarded_for blocking ip In-Reply-To: <2b4506983cf236c39c587688be8b444f.NginxMailingListRussian@forum.nginx.org> References: <2b4506983cf236c39c587688be8b444f.NginxMailingListRussian@forum.nginx.org> Message-ID: <20190926105819.GE3500@protva.ru> On Thu, Sep 26, 2019 at 06:06:54AM -0400, classic85 wrote: > всем привет > > подкажите плиз > нужно блокировать ip по заголовку: > http_x_forward_for":«10.13.2.14, 10.99.111.25:13555 > нужно блокировать только если эти два ip вместе приходят > пробовал разные способы. все равно проходит > > пример > > if ($http_x_forward_for ~ " ?10\.13\.2\.14*") { > return 403; А такой заголовок вообще есть? Бывает X-Forwarded-For. -- Eugene Berdnikov From nginx-forum на forum.nginx.org Thu Sep 26 11:01:07 2019 From: nginx-forum на forum.nginx.org (classic85) Date: Thu, 26 Sep 2019 07:01:07 -0400 Subject: nginx http_x_forwarded_for blocking ip In-Reply-To: <20190926105819.GE3500@protva.ru> References: <20190926105819.GE3500@protva.ru> Message-ID: <17c096a8b723dea1b7e83380c46fc357.NginxMailingListRussian@forum.nginx.org> http_x_forwarded_for Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285707,285713#msg-285713 From slw на zxy.spb.ru Thu Sep 26 11:59:17 2019 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Thu, 26 Sep 2019 14:59:17 +0300 Subject: nginx http_x_forwarded_for blocking ip In-Reply-To: <20190926105819.GE3500@protva.ru> References: <2b4506983cf236c39c587688be8b444f.NginxMailingListRussian@forum.nginx.org> <20190926105819.GE3500@protva.ru> Message-ID: <20190926115917.GQ3953@zxy.spb.ru> On Thu, Sep 26, 2019 at 01:58:19PM +0300, Evgeniy Berdnikov wrote: > On Thu, Sep 26, 2019 at 06:06:54AM -0400, classic85 wrote: > > всем привет > > > > подкажите плиз > > нужно блокировать ip по заголовку: > > http_x_forward_for":«10.13.2.14, 10.99.111.25:13555 > > нужно блокировать только если эти два ip вместе приходят > > пробовал разные способы. все равно проходит > > > > пример > > > > if ($http_x_forward_for ~ " ?10\.13\.2\.14*") { > > return 403; > > А такой заголовок вообще есть? Бывает X-Forwarded-For. заголовок может быть какой угодно, если он удоволтворяет грамматике. придумывай свои, сколько хочешь. From v.tolstov на selfip.ru Thu Sep 26 16:47:41 2019 From: v.tolstov на selfip.ru (Vasiliy Tolstov) Date: Thu, 26 Sep 2019 19:47:41 +0300 Subject: =?UTF-8?B?UmU6INCS0YDQtdC80Y8gc3NsIGhhbmRzaGFrZSBSU0EgJiBFQ0RTQQ==?= In-Reply-To: <20190925132700.GB1877@mdounin.ru> References: <20190925132700.GB1877@mdounin.ru> Message-ID: ср, 25 сент. 2019 г. в 16:27, Maxim Dounin : > > Начать стоит с вопроса как именно и где вы измеряете время (и > зачем). Если время измерять на клиенте - то ECDSA медленнее RSA, > такак операция проверки подписи в ECDSA сильно дороже. > > Скажем, для ECDSA P-256 и RSA 2048 ситуация выглядит так: > > $ openssl speed rsa2048 ecdsap256 > ... > sign verify sign/s verify/s > rsa 2048 bits 0.005821s 0.000168s 171.8 5958.5 > sign verify sign/s verify/s > 256 bit ecdsa (nistp256) 0.0003s 0.0012s 3588.2 858.3 > > То есть операция проверки подписи для ECDSA в разы дороже, чем для > RSA. Соответственно если измерять время handshake'а между ничего > не делающим быстрым сервером и клиентом фиксированной и не очень > большой производительности - от ECDSA-сертификатов будет сплошной > вред, ибо на него ляжет на порядок больше вычислительной работы. > > Основная польза от ECDSA-сертификатов - это существенно меньшая > нагрузка на сервер, и соответственно возможность обслуживать > существенно большее количество клиентов. Но её в таком тесте > просто не будет видно. > Прошу прощения за небольшой оффтоп, а если используется mTLS - что выгоднее использовать в плане производительности ECDSA или RSA? Учитывая что там все друг другу клиенты и серверы. -- Vasiliy Tolstov, e-mail: v.tolstov на selfip.ru From mdounin на mdounin.ru Thu Sep 26 17:15:00 2019 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 26 Sep 2019 20:15:00 +0300 Subject: =?UTF-8?B?UmU6INCS0YDQtdC80Y8gc3NsIGhhbmRzaGFrZSBSU0EgJiBFQ0RTQQ==?= In-Reply-To: References: <20190925132700.GB1877@mdounin.ru> Message-ID: <20190926171500.GG1877@mdounin.ru> Hello! On Thu, Sep 26, 2019 at 07:47:41PM +0300, Vasiliy Tolstov wrote: > ср, 25 сент. 2019 г. в 16:27, Maxim Dounin : > > > > Начать стоит с вопроса как именно и где вы измеряете время (и > > зачем). Если время измерять на клиенте - то ECDSA медленнее RSA, > > такак операция проверки подписи в ECDSA сильно дороже. > > > > Скажем, для ECDSA P-256 и RSA 2048 ситуация выглядит так: > > > > $ openssl speed rsa2048 ecdsap256 > > ... > > sign verify sign/s verify/s > > rsa 2048 bits 0.005821s 0.000168s 171.8 5958.5 > > sign verify sign/s verify/s > > 256 bit ecdsa (nistp256) 0.0003s 0.0012s 3588.2 858.3 > > > > То есть операция проверки подписи для ECDSA в разы дороже, чем для > > RSA. Соответственно если измерять время handshake'а между ничего > > не делающим быстрым сервером и клиентом фиксированной и не очень > > большой производительности - от ECDSA-сертификатов будет сплошной > > вред, ибо на него ляжет на порядок больше вычислительной работы. > > > > Основная польза от ECDSA-сертификатов - это существенно меньшая > > нагрузка на сервер, и соответственно возможность обслуживать > > существенно большее количество клиентов. Но её в таком тесте > > просто не будет видно. > > Прошу прощения за небольшой оффтоп, а если используется mTLS - что > выгоднее использовать в плане производительности ECDSA или RSA? > Учитывая что там все друг другу клиенты и серверы. Ну вот выше циферки же по аналогичным размерам ключей - в случае RSA 2048 вы получите максимальную производительность, ограниченную количеством подписей в секунду - 171.8 sign/s (стоимость верификации в разы меньше, и ей можно пренебречь), а в случае ECDSA P-256 - количеством верификаций, 858.3 verify/s (стоимостью подписи, опять же, можно пренебречь). То есть ECDSA на круг получается раз в 5 выгоднее. -- Maxim Dounin http://mdounin.ru/ From v.tolstov на selfip.ru Thu Sep 26 21:12:58 2019 From: v.tolstov на selfip.ru (Vasiliy Tolstov) Date: Fri, 27 Sep 2019 00:12:58 +0300 Subject: =?UTF-8?B?UmU6INCS0YDQtdC80Y8gc3NsIGhhbmRzaGFrZSBSU0EgJiBFQ0RTQQ==?= In-Reply-To: <20190926171500.GG1877@mdounin.ru> References: <20190925132700.GB1877@mdounin.ru> <20190926171500.GG1877@mdounin.ru> Message-ID: чт, 26 сент. 2019 г. в 20:15, Maxim Dounin : > > Hello! > > On Thu, Sep 26, 2019 at 07:47:41PM +0300, Vasiliy Tolstov wrote: > > > ср, 25 сент. 2019 г. в 16:27, Maxim Dounin : > > > > > > Начать стоит с вопроса как именно и где вы измеряете время (и > > > зачем). Если время измерять на клиенте - то ECDSA медленнее RSA, > > > такак операция проверки подписи в ECDSA сильно дороже. > > > > > > Скажем, для ECDSA P-256 и RSA 2048 ситуация выглядит так: > > > > > > $ openssl speed rsa2048 ecdsap256 > > > ... > > > sign verify sign/s verify/s > > > rsa 2048 bits 0.005821s 0.000168s 171.8 5958.5 > > > sign verify sign/s verify/s > > > 256 bit ecdsa (nistp256) 0.0003s 0.0012s 3588.2 858.3 > > > > > > То есть операция проверки подписи для ECDSA в разы дороже, чем для > > > RSA. Соответственно если измерять время handshake'а между ничего > > > не делающим быстрым сервером и клиентом фиксированной и не очень > > > большой производительности - от ECDSA-сертификатов будет сплошной > > > вред, ибо на него ляжет на порядок больше вычислительной работы. > > > > > > Основная польза от ECDSA-сертификатов - это существенно меньшая > > > нагрузка на сервер, и соответственно возможность обслуживать > > > существенно большее количество клиентов. Но её в таком тесте > > > просто не будет видно. > > > > Прошу прощения за небольшой оффтоп, а если используется mTLS - что > > выгоднее использовать в плане производительности ECDSA или RSA? > > Учитывая что там все друг другу клиенты и серверы. > > Ну вот выше циферки же по аналогичным размерам ключей - в случае > RSA 2048 вы получите максимальную производительность, ограниченную > количеством подписей в секунду - 171.8 sign/s (стоимость > верификации в разы меньше, и ей можно пренебречь), а в случае > ECDSA P-256 - количеством верификаций, 858.3 verify/s (стоимостью > подписи, опять же, можно пренебречь). То есть ECDSA на круг > получается раз в 5 выгоднее. > Видимо немного неверно сформулировал вопрос или не понял ответ. Я имел ввиду ситуацию, когда есть допустим пара сервисов, которые просто занимаются выдачей по jwt токену ключа подписанного public ключа. Клиент посылает такому сервису jwt токен и csr. На выходе он будет иметь подписанный паблик ключ. В такой схеме, что выгоднее использовать на сервисах, к которым потом будут подключаться? Время жизни ключа - ротация, допустим 10 минут. У меня на сервере выходит такое: sign verify sign/s verify/s rsa 0.002298s 0.000067s 435.2 14924.7 sign verify sign/s verify/s ecdsa 0.0001s 0.0002s 16490.3 4867.9 Как я понимаю в таком случае выигрышнее будет скорость verify ? -- Vasiliy Tolstov, e-mail: v.tolstov на selfip.ru From chipitsine на gmail.com Fri Sep 27 11:29:52 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 27 Sep 2019 16:29:52 +0500 Subject: nginx http_x_forwarded_for blocking ip In-Reply-To: References: Message-ID: map $http_x_forward_for $temp { default ''; ~regex1 $http_x_forward_for; } map $temp $final { default ''; ~regex2 1; } if ($final = 1) { return 403; } чт, 26 сент. 2019 г. в 15:49, classic85 : > а можно пример? пожалуйста слева направо да > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,285707,285711#msg-285711 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Fri Sep 27 11:34:13 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 27 Sep 2019 16:34:13 +0500 Subject: =?UTF-8?B?UmU6INCS0YDQtdC80Y8gc3NsIGhhbmRzaGFrZSBSU0EgJiBFQ0RTQQ==?= In-Reply-To: References: <20190925132700.GB1877@mdounin.ru> <20190926171500.GG1877@mdounin.ru> Message-ID: пт, 27 сент. 2019 г. в 02:13, Vasiliy Tolstov : > чт, 26 сент. 2019 г. в 20:15, Maxim Dounin : > > > > Hello! > > > > On Thu, Sep 26, 2019 at 07:47:41PM +0300, Vasiliy Tolstov wrote: > > > > > ср, 25 сент. 2019 г. в 16:27, Maxim Dounin : > > > > > > > > Начать стоит с вопроса как именно и где вы измеряете время (и > > > > зачем). Если время измерять на клиенте - то ECDSA медленнее RSA, > > > > такак операция проверки подписи в ECDSA сильно дороже. > > > > > > > > Скажем, для ECDSA P-256 и RSA 2048 ситуация выглядит так: > > > > > > > > $ openssl speed rsa2048 ecdsap256 > > > > ... > > > > sign verify sign/s verify/s > > > > rsa 2048 bits 0.005821s 0.000168s 171.8 5958.5 > > > > sign verify sign/s verify/s > > > > 256 bit ecdsa (nistp256) 0.0003s 0.0012s 3588.2 858.3 > > > > > > > > То есть операция проверки подписи для ECDSA в разы дороже, чем для > > > > RSA. Соответственно если измерять время handshake'а между ничего > > > > не делающим быстрым сервером и клиентом фиксированной и не очень > > > > большой производительности - от ECDSA-сертификатов будет сплошной > > > > вред, ибо на него ляжет на порядок больше вычислительной работы. > > > > > > > > Основная польза от ECDSA-сертификатов - это существенно меньшая > > > > нагрузка на сервер, и соответственно возможность обслуживать > > > > существенно большее количество клиентов. Но её в таком тесте > > > > просто не будет видно. > > > > > > Прошу прощения за небольшой оффтоп, а если используется mTLS - что > > > выгоднее использовать в плане производительности ECDSA или RSA? > > > Учитывая что там все друг другу клиенты и серверы. > > > > Ну вот выше циферки же по аналогичным размерам ключей - в случае > > RSA 2048 вы получите максимальную производительность, ограниченную > > количеством подписей в секунду - 171.8 sign/s (стоимость > > верификации в разы меньше, и ей можно пренебречь), а в случае > > ECDSA P-256 - количеством верификаций, 858.3 verify/s (стоимостью > > подписи, опять же, можно пренебречь). То есть ECDSA на круг > > получается раз в 5 выгоднее. > > > > > Видимо немного неверно сформулировал вопрос или не понял ответ. > Я имел ввиду ситуацию, когда есть допустим пара сервисов, которые > просто занимаются выдачей по jwt токену ключа подписанного public > ключа. Клиент посылает такому сервису jwt токен и csr. На выходе он > будет иметь подписанный паблик ключ. > В такой схеме, что выгоднее использовать на сервисах, к которым потом > будут подключаться? > параметры у вас следующие 1) переиспользование http сессий (параметр keepalive_requests 100, который в дефолтном варианте ограничивает кипэлайв 100 запросами) 2) переиспользование ssl сессий (ssl tickets, ssl sessions) - если оно не используется, вы попадете как раз на замеры, которые вы привели (это замеры для полных хендшейков) профилировать, на что уходит цпу, можно например, вот этим http://nginx.org/ru/docs/ngx_google_perftools_module.html в случае, если сессии не переиспользуются, действительно будет так, что ECDSA раза в 4 дешевле. если переиспользуются, по нашему опыту затраты на ssl теряются на фоне остального (но вы проверьте) > Время жизни ключа - ротация, допустим 10 минут. > У меня на сервере выходит такое: > sign verify sign/s verify/s > rsa 0.002298s 0.000067s 435.2 14924.7 > sign verify sign/s verify/s > ecdsa 0.0001s 0.0002s 16490.3 4867.9 > > Как я понимаю в таком случае выигрышнее будет скорость verify ? > > -- > Vasiliy Tolstov, > e-mail: v.tolstov на selfip.ru > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From v.tolstov на selfip.ru Fri Sep 27 23:34:38 2019 From: v.tolstov на selfip.ru (Vasiliy Tolstov) Date: Sat, 28 Sep 2019 02:34:38 +0300 Subject: =?UTF-8?B?UmU6INCS0YDQtdC80Y8gc3NsIGhhbmRzaGFrZSBSU0EgJiBFQ0RTQQ==?= In-Reply-To: References: <20190925132700.GB1877@mdounin.ru> <20190926171500.GG1877@mdounin.ru> Message-ID: пт, 27 сент. 2019 г. в 14:34, Илья Шипицин : > > > > пт, 27 сент. 2019 г. в 02:13, Vasiliy Tolstov : >> >> чт, 26 сент. 2019 г. в 20:15, Maxim Dounin : >> > >> > Hello! >> > >> > On Thu, Sep 26, 2019 at 07:47:41PM +0300, Vasiliy Tolstov wrote: >> > >> > > ср, 25 сент. 2019 г. в 16:27, Maxim Dounin : >> > > > >> > > > Начать стоит с вопроса как именно и где вы измеряете время (и >> > > > зачем). Если время измерять на клиенте - то ECDSA медленнее RSA, >> > > > такак операция проверки подписи в ECDSA сильно дороже. >> > > > >> > > > Скажем, для ECDSA P-256 и RSA 2048 ситуация выглядит так: >> > > > >> > > > $ openssl speed rsa2048 ecdsap256 >> > > > ... >> > > > sign verify sign/s verify/s >> > > > rsa 2048 bits 0.005821s 0.000168s 171.8 5958.5 >> > > > sign verify sign/s verify/s >> > > > 256 bit ecdsa (nistp256) 0.0003s 0.0012s 3588.2 858.3 >> > > > >> > > > То есть операция проверки подписи для ECDSA в разы дороже, чем для >> > > > RSA. Соответственно если измерять время handshake'а между ничего >> > > > не делающим быстрым сервером и клиентом фиксированной и не очень >> > > > большой производительности - от ECDSA-сертификатов будет сплошной >> > > > вред, ибо на него ляжет на порядок больше вычислительной работы. >> > > > >> > > > Основная польза от ECDSA-сертификатов - это существенно меньшая >> > > > нагрузка на сервер, и соответственно возможность обслуживать >> > > > существенно большее количество клиентов. Но её в таком тесте >> > > > просто не будет видно. >> > > >> > > Прошу прощения за небольшой оффтоп, а если используется mTLS - что >> > > выгоднее использовать в плане производительности ECDSA или RSA? >> > > Учитывая что там все друг другу клиенты и серверы. >> > >> > Ну вот выше циферки же по аналогичным размерам ключей - в случае >> > RSA 2048 вы получите максимальную производительность, ограниченную >> > количеством подписей в секунду - 171.8 sign/s (стоимость >> > верификации в разы меньше, и ей можно пренебречь), а в случае >> > ECDSA P-256 - количеством верификаций, 858.3 verify/s (стоимостью >> > подписи, опять же, можно пренебречь). То есть ECDSA на круг >> > получается раз в 5 выгоднее. >> > >> >> >> Видимо немного неверно сформулировал вопрос или не понял ответ. >> Я имел ввиду ситуацию, когда есть допустим пара сервисов, которые >> просто занимаются выдачей по jwt токену ключа подписанного public >> ключа. Клиент посылает такому сервису jwt токен и csr. На выходе он >> будет иметь подписанный паблик ключ. >> В такой схеме, что выгоднее использовать на сервисах, к которым потом >> будут подключаться? > > > параметры у вас следующие > > 1) переиспользование http сессий (параметр keepalive_requests 100, который в дефолтном варианте ограничивает кипэлайв 100 запросами) > 2) переиспользование ssl сессий (ssl tickets, ssl sessions) - если оно не используется, вы попадете как раз на замеры, которые вы привели (это замеры для полных хендшейков) > > профилировать, на что уходит цпу, можно например, вот этим > > http://nginx.org/ru/docs/ngx_google_perftools_module.html > > > в случае, если сессии не переиспользуются, действительно будет так, что ECDSA раза в 4 дешевле. > если переиспользуются, по нашему опыту затраты на ssl теряются на фоне остального (но вы проверьте) > Понял, спасибо! Вопрос скорее был с заделом на будущее, сейчас действительно проблем нет и в целом действительно затраты на ssl малы по сравнению со всем остальным. -- Vasiliy Tolstov, e-mail: v.tolstov на selfip.ru From chipitsine на gmail.com Sat Sep 28 08:42:49 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sat, 28 Sep 2019 13:42:49 +0500 Subject: =?UTF-8?B?0YLQtdGB0YLQuNGA0L7QstCw0L3QuNC1IGh0dHAyINGD0YLQuNC70LjRgtC+0Lkg?= =?UTF-8?B?aDJzcGVj?= Message-ID: привет! если проверять nginx-1.17.4 вот этой утилитой https://github.com/summerwind/h2spec то несколько десятков тестов фейлятся. можете прокомментировать ? [ilia на localhost h2spec]$ ./h2spec -p 443 -h xxx.xxx.ru -t http2 Hypertext Transfer Protocol Version 2 (HTTP/2) 3. Starting HTTP/2 3.5. HTTP/2 Connection Preface ✔ 1: Sends client connection preface ✔ 2: Sends invalid connection preface 4. HTTP Frames 4.1. Frame Format ✔ 1: Sends a frame with unknown type ✔ 2: Sends a frame with undefined flag ✔ 3: Sends a frame with reserved field bit 4.2. Frame Size ✔ 1: Sends a DATA frame with 2^14 octets in length × 2: Sends a large size DATA frame that exceeds the SETTINGS_MAX_FRAME_SIZE -> The endpoint MUST send an error code of FRAME_SIZE_ERROR. Expected: GOAWAY Frame (Error Code: FRAME_SIZE_ERROR) RST_STREAM Frame (Error Code: FRAME_SIZE_ERROR) Connection closed Actual: WINDOW_UPDATE Frame (length:4, flags:0x00, stream_id:1) ✔ 3: Sends a large size HEADERS frame that exceeds the SETTINGS_MAX_FRAME_SIZE 4.3. Header Compression and Decompression ✔ 1: Sends invalid header block fragment ✔ 2: Sends a PRIORITY frame while sending the header blocks ✔ 3: Sends a HEADERS frame to another stream while sending the header blocks 5. Streams and Multiplexing 5.1. Stream States × 1: idle: Sends a DATA frame -> The endpoint MUST treat this as a connection error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: Timeout × 2: idle: Sends a RST_STREAM frame -> The endpoint MUST treat this as a connection error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: Timeout × 3: idle: Sends a WINDOW_UPDATE frame -> The endpoint MUST treat this as a connection error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: Timeout ✔ 4: idle: Sends a CONTINUATION frame ✔ 5: half closed (remote): Sends a DATA frame ✔ 6: half closed (remote): Sends a HEADERS frame ✔ 7: half closed (remote): Sends a CONTINUATION frame × 8: closed: Sends a DATA frame after sending RST_STREAM frame -> The endpoint MUST treat this as a stream error of type STREAM_CLOSED. Expected: GOAWAY Frame (Error Code: STREAM_CLOSED) RST_STREAM Frame (Error Code: STREAM_CLOSED) Connection closed Actual: WINDOW_UPDATE Frame (length:4, flags:0x00, stream_id:1) ✔ 9: closed: Sends a HEADERS frame after sending RST_STREAM frame ✔ 10: closed: Sends a CONTINUATION frame after sending RST_STREAM frame × 11: closed: Sends a DATA frame -> The endpoint MUST treat this as a connection error of type STREAM_CLOSED. Expected: GOAWAY Frame (Error Code: STREAM_CLOSED) RST_STREAM Frame (Error Code: STREAM_CLOSED) Connection closed Actual: Timeout ✔ 12: closed: Sends a HEADERS frame ✔ 13: closed: Sends a CONTINUATION frame 5.1.1. Stream Identifiers ✔ 1: Sends even-numbered stream identifier ✔ 2: Sends stream identifier that is numerically smaller than previous 5.1.2. Stream Concurrency ✔ 1: Sends HEADERS frames that causes their advertised concurrent stream limit to be exceeded 5.3. Stream Priority 5.3.1. Stream Dependencies ✔ 1: Sends HEADERS frame that depend on itself ✔ 2: Sends PRIORITY frame that depend on itself 5.4. Error Handling 5.4.1. Connection Error Handling × 1: Sends an invalid PING frame for connection close -> The endpoint MUST close the TCP connection Expected: Connection closed Actual: PING Frame (length:8, flags:0x01, stream_id:0) 5.5. Extending HTTP/2 ✔ 1: Sends an unknown extension frame ✔ 2: Sends an unknown extension frame in the middle of a header block 6. Frame Definitions 6.1. DATA × 1: Sends a DATA frame with 0x0 stream identifier -> The endpoint MUST respond with a connection error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: Timeout ✔ 2: Sends a DATA frame on the stream that is not in "open" or "half-closed (local)" state ✔ 3: Sends a DATA frame with invalid pad length 6.2. HEADERS ✔ 1: Sends a HEADERS frame without the END_HEADERS flag, and a PRIORITY frame ✔ 2: Sends a HEADERS frame to another stream while sending a HEADERS frame ✔ 3: Sends a HEADERS frame with 0x0 stream identifier ✔ 4: Sends a HEADERS frame with invalid pad length 6.3. PRIORITY ✔ 1: Sends a PRIORITY frame with 0x0 stream identifier ✔ 2: Sends a PRIORITY frame with a length other than 5 octets 6.4. RST_STREAM ✔ 1: Sends a RST_STREAM frame with 0x0 stream identifier × 2: Sends a RST_STREAM frame on a idle stream -> The endpoint MUST respond with a connection error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: Timeout ✔ 3: Sends a RST_STREAM frame with a length other than 4 octets 6.5. SETTINGS ✔ 1: Sends a SETTINGS frame with ACK flag and payload × 2: Sends a SETTINGS frame with a stream identifier other than 0x0 -> The endpoint MUST respond with a connection error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: SETTINGS Frame (length:0, flags:0x01, stream_id:0) ✔ 3: Sends a SETTINGS frame with a length other than a multiple of 6 octets 6.5.2. Defined SETTINGS Parameters ✔ 1: SETTINGS_ENABLE_PUSH (0x2): Sends the value other than 0 or 1 ✔ 2: SETTINGS_INITIAL_WINDOW_SIZE (0x4): Sends the value above the maximum flow control window size ✔ 3: SETTINGS_MAX_FRAME_SIZE (0x5): Sends the value below the initial value ✔ 4: SETTINGS_MAX_FRAME_SIZE (0x5): Sends the value above the maximum allowed frame size ✔ 5: Sends a SETTINGS frame with unknown identifier 6.5.3. Settings Synchronization ✔ 1: Sends multiple values of SETTINGS_INITIAL_WINDOW_SIZE ✔ 2: Sends a SETTINGS frame without ACK flag 6.7. PING ✔ 1: Sends a PING frame ✔ 2: Sends a PING frame with ACK × 3: Sends a PING frame with a stream identifier field value other than 0x0 -> The endpoint MUST respond with a connection error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: PING Frame (length:8, flags:0x01, stream_id:0) ✔ 4: Sends a PING frame with a length field value other than 8 6.8. GOAWAY × 1: Sends a GOAWAY frame with a stream identifier other than 0x0 -> The endpoint MUST treat this as a connection error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: Timeout 6.9. WINDOW_UPDATE ✔ 1: Sends a WINDOW_UPDATE frame with a flow control window increment of 0 ✔ 2: Sends a WINDOW_UPDATE frame with a flow control window increment of 0 on a stream ✔ 3: Sends a WINDOW_UPDATE frame with a length other than 4 octets 6.9.1. The Flow-Control Window ✔ 1: Sends SETTINGS frame to set the initial window size to 1 and sends HEADERS frame ✔ 2: Sends multiple WINDOW_UPDATE frames increasing the flow control window to above 2^31-1 ✔ 3: Sends multiple WINDOW_UPDATE frames increasing the flow control window to above 2^31-1 on a stream 6.9.2. Initial Flow-Control Window Size ✔ 1: Changes SETTINGS_INITIAL_WINDOW_SIZE after sending HEADERS frame ✔ 2: Sends a SETTINGS frame for window size to be negative ✔ 3: Sends a SETTINGS_INITIAL_WINDOW_SIZE settings with an exceeded maximum window size value 6.10. CONTINUATION ✔ 1: Sends multiple CONTINUATION frames preceded by a HEADERS frame ✔ 2: Sends a CONTINUATION frame followed by any frame other than CONTINUATION ✔ 3: Sends a CONTINUATION frame with 0x0 stream identifier ✔ 4: Sends a CONTINUATION frame preceded by a HEADERS frame with END_HEADERS flag ✔ 5: Sends a CONTINUATION frame preceded by a CONTINUATION frame with END_HEADERS flag ✔ 6: Sends a CONTINUATION frame preceded by a DATA frame 7. Error Codes ✔ 1: Sends a GOAWAY frame with unknown error code ✔ 2: Sends a RST_STREAM frame with unknown error code 8. HTTP Message Exchanges 8.1. HTTP Request/Response Exchange ✔ 1: Sends a second HEADERS frame without the END_STREAM flag 8.1.2. HTTP Header Fields ✔ 1: Sends a HEADERS frame that contains the header field name in uppercase letters 8.1.2.1. Pseudo-Header Fields × 1: Sends a HEADERS frame that contains a unknown pseudo-header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) × 2: Sends a HEADERS frame that contains the pseudo-header field defined for response -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) ✔ 3: Sends a HEADERS frame that contains a pseudo-header field as trailers × 4: Sends a HEADERS frame that contains a pseudo-header field that appears in a header block after a regular header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:0, flags:0x01, stream_id:1) 8.1.2.2. Connection-Specific Header Fields × 1: Sends a HEADERS frame that contains the connection-specific header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:0, flags:0x01, stream_id:1) × 2: Sends a HEADERS frame that contains the TE header field with any value other than "trailers" -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:0, flags:0x01, stream_id:1) 8.1.2.3. Request Pseudo-Header Fields × 1: Sends a HEADERS frame with empty ":path" pseudo-header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) × 2: Sends a HEADERS frame that omits ":method" pseudo-header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) × 3: Sends a HEADERS frame that omits ":scheme" pseudo-header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) × 4: Sends a HEADERS frame that omits ":path" pseudo-header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) × 5: Sends a HEADERS frame with duplicated ":method" pseudo-header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) × 6: Sends a HEADERS frame with duplicated ":scheme" pseudo-header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) × 7: Sends a HEADERS frame with duplicated ":path" pseudo-header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) 8.1.2.6. Malformed Requests and Responses × 1: Sends a HEADERS frame with the "content-length" header field which does not equal the DATA frame payload length -> The endpoint MUST treat this as a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) × 2: Sends a HEADERS frame with the "content-length" header field which does not equal the sum of the multiple DATA frames payload length -> The endpoint MUST treat this as a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) 8.2. Server Push ✔ 1: Sends a PUSH_PROMISE frame Failures: Hypertext Transfer Protocol Version 2 (HTTP/2) 4. HTTP Frames 4.2. Frame Size × 2: Sends a large size DATA frame that exceeds the SETTINGS_MAX_FRAME_SIZE -> The endpoint MUST send an error code of FRAME_SIZE_ERROR. Expected: GOAWAY Frame (Error Code: FRAME_SIZE_ERROR) RST_STREAM Frame (Error Code: FRAME_SIZE_ERROR) Connection closed Actual: WINDOW_UPDATE Frame (length:4, flags:0x00, stream_id:1) 5. Streams and Multiplexing 5.1. Stream States × 1: idle: Sends a DATA frame -> The endpoint MUST treat this as a connection error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: Timeout × 2: idle: Sends a RST_STREAM frame -> The endpoint MUST treat this as a connection error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: Timeout × 3: idle: Sends a WINDOW_UPDATE frame -> The endpoint MUST treat this as a connection error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: Timeout × 8: closed: Sends a DATA frame after sending RST_STREAM frame -> The endpoint MUST treat this as a stream error of type STREAM_CLOSED. Expected: GOAWAY Frame (Error Code: STREAM_CLOSED) RST_STREAM Frame (Error Code: STREAM_CLOSED) Connection closed Actual: WINDOW_UPDATE Frame (length:4, flags:0x00, stream_id:1) × 11: closed: Sends a DATA frame -> The endpoint MUST treat this as a connection error of type STREAM_CLOSED. Expected: GOAWAY Frame (Error Code: STREAM_CLOSED) RST_STREAM Frame (Error Code: STREAM_CLOSED) Connection closed Actual: Timeout 5.4. Error Handling 5.4.1. Connection Error Handling × 1: Sends an invalid PING frame for connection close -> The endpoint MUST close the TCP connection Expected: Connection closed Actual: PING Frame (length:8, flags:0x01, stream_id:0) 6. Frame Definitions 6.1. DATA × 1: Sends a DATA frame with 0x0 stream identifier -> The endpoint MUST respond with a connection error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: Timeout 6.4. RST_STREAM × 2: Sends a RST_STREAM frame on a idle stream -> The endpoint MUST respond with a connection error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: Timeout 6.5. SETTINGS × 2: Sends a SETTINGS frame with a stream identifier other than 0x0 -> The endpoint MUST respond with a connection error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: SETTINGS Frame (length:0, flags:0x01, stream_id:0) 6.7. PING × 3: Sends a PING frame with a stream identifier field value other than 0x0 -> The endpoint MUST respond with a connection error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: PING Frame (length:8, flags:0x01, stream_id:0) 6.8. GOAWAY × 1: Sends a GOAWAY frame with a stream identifier other than 0x0 -> The endpoint MUST treat this as a connection error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: Timeout 8. HTTP Message Exchanges 8.1. HTTP Request/Response Exchange 8.1.2. HTTP Header Fields 8.1.2.1. Pseudo-Header Fields × 1: Sends a HEADERS frame that contains a unknown pseudo-header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) × 2: Sends a HEADERS frame that contains the pseudo-header field defined for response -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) × 4: Sends a HEADERS frame that contains a pseudo-header field that appears in a header block after a regular header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:0, flags:0x01, stream_id:1) 8.1.2.2. Connection-Specific Header Fields × 1: Sends a HEADERS frame that contains the connection-specific header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:0, flags:0x01, stream_id:1) × 2: Sends a HEADERS frame that contains the TE header field with any value other than "trailers" -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:0, flags:0x01, stream_id:1) 8.1.2.3. Request Pseudo-Header Fields × 1: Sends a HEADERS frame with empty ":path" pseudo-header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) × 2: Sends a HEADERS frame that omits ":method" pseudo-header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) × 3: Sends a HEADERS frame that omits ":scheme" pseudo-header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) × 4: Sends a HEADERS frame that omits ":path" pseudo-header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) × 5: Sends a HEADERS frame with duplicated ":method" pseudo-header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) × 6: Sends a HEADERS frame with duplicated ":scheme" pseudo-header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) × 7: Sends a HEADERS frame with duplicated ":path" pseudo-header field -> The endpoint MUST respond with a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) 8.1.2.6. Malformed Requests and Responses × 1: Sends a HEADERS frame with the "content-length" header field which does not equal the DATA frame payload length -> The endpoint MUST treat this as a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) × 2: Sends a HEADERS frame with the "content-length" header field which does not equal the sum of the multiple DATA frames payload length -> The endpoint MUST treat this as a stream error of type PROTOCOL_ERROR. Expected: GOAWAY Frame (Error Code: PROTOCOL_ERROR) RST_STREAM Frame (Error Code: PROTOCOL_ERROR) Connection closed Actual: DATA Frame (length:150, flags:0x01, stream_id:1) Finished in 72.3573 seconds 94 tests, 68 passed, 0 skipped, 26 failed [ilia на localhost h2spec]$ ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Mon Sep 30 04:40:54 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Mon, 30 Sep 2019 00:40:54 -0400 Subject: Non-idempotent requests vs. upstream failover Message-ID: <844ea1a30cc7c6e061002d329ffa5e40.NginxMailingListRussian@forum.nginx.org> В случае если proxy апстрим не доступен на уровне сокета (ECONNREFUSED, а не просто вернулось HTTP 5хх), будет ли nginx ретраить POST запрос на следующих апстримах? По идее должен т.к. запрос никем не был принят и обработан. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285751,285751#msg-285751 From pluknet на nginx.com Mon Sep 30 09:57:35 2019 From: pluknet на nginx.com (Sergey Kandaurov) Date: Mon, 30 Sep 2019 12:57:35 +0300 Subject: Non-idempotent requests vs. upstream failover In-Reply-To: <844ea1a30cc7c6e061002d329ffa5e40.NginxMailingListRussian@forum.nginx.org> References: <844ea1a30cc7c6e061002d329ffa5e40.NginxMailingListRussian@forum.nginx.org> Message-ID: > On 30 Sep 2019, at 07:40, rihad wrote: > > В случае если proxy апстрим не доступен на уровне сокета (ECONNREFUSED, а не > просто вернулось HTTP 5хх), будет ли nginx ретраить POST запрос на следующих > апстримах? По идее должен т.к. запрос никем не был принят и обработан. В данном случае по умолчанию будет попытка выбрать следующий сервер, т.к. запрос ещё не был отправлен. Подробнее тут: http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#non_idempotent -- Sergey Kandaurov From nginx-forum на forum.nginx.org Mon Sep 30 10:44:17 2019 From: nginx-forum на forum.nginx.org (rihad) Date: Mon, 30 Sep 2019 06:44:17 -0400 Subject: Non-idempotent requests vs. upstream failover In-Reply-To: References: Message-ID: <404d30f949e73ae3f8e1b4e4ce5af249.NginxMailingListRussian@forum.nginx.org> Спасибо, а логируется ли в таких случаях в error log? Или только если все апстримы фейлнули? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285751,285753#msg-285753 From chipitsine на gmail.com Mon Sep 30 11:07:20 2019 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 30 Sep 2019 16:07:20 +0500 Subject: Non-idempotent requests vs. upstream failover In-Reply-To: <404d30f949e73ae3f8e1b4e4ce5af249.NginxMailingListRussian@forum.nginx.org> References: <404d30f949e73ae3f8e1b4e4ce5af249.NginxMailingListRussian@forum.nginx.org> Message-ID: добрый день, вы можете не очень сложным образом собрать стенд (и пострелять по нему curl-ом в режиме POST) ответы на ваши вопросы зависят от многих "если". такие вещи лучше обкатывать на стенде. что-то типа TDD (test driven development) upstream upstream1 { server 127.0.0.1:81; server 127.0.0.1:82; } server { listen 127.0.0.1:80; location / { proxy_pass http://upstream1; } } server { listen 127.0.0.1:82; location / { return 200; } } пн, 30 сент. 2019 г. в 15:44, rihad : > Спасибо, а логируется ли в таких случаях в error log? Или только если все > апстримы фейлнули? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,285751,285753#msg-285753 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From pluknet на nginx.com Mon Sep 30 17:20:52 2019 From: pluknet на nginx.com (Sergey Kandaurov) Date: Mon, 30 Sep 2019 20:20:52 +0300 Subject: =?UTF-8?B?UmU6INGC0LXRgdGC0LjRgNC+0LLQsNC90LjQtSBodHRwMiDRg9GC0LjQu9C40YI=?= =?UTF-8?B?0L7QuSBoMnNwZWM=?= In-Reply-To: References: Message-ID: <4A797324-AC23-43DA-944F-2A4CCEF2165F@nginx.com> > On 28 Sep 2019, at 11:42, Илья Шипицин wrote: > > привет! > > если проверять nginx-1.17.4 вот этой утилитой https://github.com/summerwind/h2spec > то несколько десятков тестов фейлятся. можете прокомментировать ? > > [ilia на localhost h2spec]$ ./h2spec -p 443 -h xxx.xxx.ru -t http2 > Hypertext Transfer Protocol Version 2 (HTTP/2) > 3. Starting HTTP/2 > 3.5. HTTP/2 Connection Preface > ✔ 1: Sends client connection preface > ✔ 2: Sends invalid connection preface > > 4. HTTP Frames > 4.1. Frame Format > ✔ 1: Sends a frame with unknown type > ✔ 2: Sends a frame with undefined flag > ✔ 3: Sends a frame with reserved field bit > > 4.2. Frame Size > ✔ 1: Sends a DATA frame with 2^14 octets in length Здесь тестируется что-то другое. Тест не проверяет, что мы отправляем максимальный SETTINGS_MAX_FRAME_SIZE, либо проверяет, но тогда описание не соответствует тому, что тестируется, т.к. согласно данным объективного контроля DATA имеет длину 16777215 байт. Далее, если тест наступит на client_max_body_size (по умолчанию 1m) и nginx вернёт HTTP 413, не дочитав собственно тело, тест всё равно будет признан успешным, т.к. получен HEADERS. Поэтому вопрос, что здесь тестируется. > × 2: Sends a large size DATA frame that exceeds the SETTINGS_MAX_FRAME_SIZE > -> The endpoint MUST send an error code of FRAME_SIZE_ERROR. > Expected: GOAWAY Frame (Error Code: FRAME_SIZE_ERROR) > RST_STREAM Frame (Error Code: FRAME_SIZE_ERROR) > Connection closed > Actual: WINDOW_UPDATE Frame (length:4, flags:0x00, stream_id:1) Вопреки описанию, тест закрывает соединение по собственной инициативе через две с небольшим секунды после отправки HEADERS. > ✔ 3: Sends a large size HEADERS frame that exceeds the SETTINGS_MAX_FRAME_SIZE Здесь тестируется что-то другое, см. выше по SETTINGS_MAX_FRAME_SIZE. Тест отправляет HEADERS длиной > SETTINGS_MAX_FRAME_SIZE по умолчанию и проверяет получение GOAWAY, который приходит, но по другой причине (и с другим кодом). А именно - в следствие достижения собственного лимита в nginx, который настраивается директивой http2_max_header_size. Дальше не смотрел. -- Sergey Kandaurov