Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
чт, 30 апр. 2020 г. в 01:59, Slawa Olhovchenkov : > On Thu, Apr 30, 2020 at 01:41:13AM +0500, Илья Шипицин wrote: > > > чт, 30 апр. 2020 г. в 00:00, Evgeniy Berdnikov : > > > > > On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote: > > > > Но предполагаю, что клиенту отказаться от push'а проще, чем сделать > > > > дополнительный запрос к ресурсу. > > > > > > Если клиент умеет cache digest, то да, может отказаться заранее. > > > А если нет, то к тому моменту, когда клиент сможет отклонить push, > > > данные уже летят по сети и отъедают пропускную способность канала, > > > это обстоятельство может навредить желанию загрузить все причандалы > > > к странице побыстрее. > > > > > > Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю > > > профит от сложной и очень тяжёлой технологии". И push в том ряду. > > > > > > > > > http2 решает искуственную проблему - у браузера по каким-то странным > > причинам ограничего количество одновременных > > tcp сессий, обычно двумя сессиями. И, допустим, браузер параллельно тащит > > два оочень медленных ответа, все остальные > > элементы, как то css стили, которые нужны для того, чтобы отрендерить > > страницу, на паузе. > > > > т.е. браузер решил сам себе ограничить количество сессий - удачи ему. > > а потом пришли разработчики http2 и сказали "а давайте внутри одной tcp > > сессии будет типа еще один инкапсулированный tcp > > с мультиплексированием". ну то есть нам дорого открыть несколько честных > > tcp потоков, лучше мы заморочимся тем, что будем > > мультиплексировать tcp внутри tcp. > > нет-нет. > не так все было. > много соединений на сервер == много одновременных запросов == большая > нагрузка на сервер (особенно если там апач или томкат). > это же почти DDoS! > видимо, Слава забыл тег в приведенном (выдуманном) примере описано, что надо защищать сервер апач от ддоса, притом, что задача не позволить открыть больше конекшенов, чем сервер способен осилить, выглядит скорее, как задача самого сервера но да, какая-то подобная логика вполне могла быть в этой всей истории. > > разработчики браузеров сказали -- а мы за все хорошее и против всего > плохого! > ограничим число одновоременных запросов от каждого браузера двумя! > фиг вам зловереды а не DDoS! > > прошло некоторое время, все уже забыли почему так получилось и > разрабочки стандарта придумали э... монстра. > > ну надеюсь теперь все догадываются что будет дальше? > подсказываю: зловредные страницы котрые будут содержать миллионы > ссылок на http2 сайты которые будут по двум соединениям делать 100500 > одновременных запросов на разные ресурсы. после этого разработчки > браузеров разрешат по каждому http2 соединению делать не более 2 > запосов. > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
On Thu, Apr 30, 2020 at 01:41:13AM +0500, Илья Шипицин wrote: > чт, 30 апр. 2020 г. в 00:00, Evgeniy Berdnikov : > > > On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote: > > > Но предполагаю, что клиенту отказаться от push'а проще, чем сделать > > > дополнительный запрос к ресурсу. > > > > Если клиент умеет cache digest, то да, может отказаться заранее. > > А если нет, то к тому моменту, когда клиент сможет отклонить push, > > данные уже летят по сети и отъедают пропускную способность канала, > > это обстоятельство может навредить желанию загрузить все причандалы > > к странице побыстрее. > > > > Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю > > профит от сложной и очень тяжёлой технологии". И push в том ряду. > > > > > http2 решает искуственную проблему - у браузера по каким-то странным > причинам ограничего количество одновременных > tcp сессий, обычно двумя сессиями. И, допустим, браузер параллельно тащит > два оочень медленных ответа, все остальные > элементы, как то css стили, которые нужны для того, чтобы отрендерить > страницу, на паузе. > > т.е. браузер решил сам себе ограничить количество сессий - удачи ему. > а потом пришли разработчики http2 и сказали "а давайте внутри одной tcp > сессии будет типа еще один инкапсулированный tcp > с мультиплексированием". ну то есть нам дорого открыть несколько честных > tcp потоков, лучше мы заморочимся тем, что будем > мультиплексировать tcp внутри tcp. нет-нет. не так все было. много соединений на сервер == много одновременных запросов == большая нагрузка на сервер (особенно если там апач или томкат). это же почти DDoS! разработчики браузеров сказали -- а мы за все хорошее и против всего плохого! ограничим число одновоременных запросов от каждого браузера двумя! фиг вам зловереды а не DDoS! прошло некоторое время, все уже забыли почему так получилось и разрабочки стандарта придумали э... монстра. ну надеюсь теперь все догадываются что будет дальше? подсказываю: зловредные страницы котрые будут содержать миллионы ссылок на http2 сайты которые будут по двум соединениям делать 100500 одновременных запросов на разные ресурсы. после этого разработчки браузеров разрешат по каждому http2 соединению делать не более 2 запосов. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
чт, 30 апр. 2020 г. в 00:00, Evgeniy Berdnikov : > On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote: > > Но предполагаю, что клиенту отказаться от push'а проще, чем сделать > > дополнительный запрос к ресурсу. > > Если клиент умеет cache digest, то да, может отказаться заранее. > А если нет, то к тому моменту, когда клиент сможет отклонить push, > данные уже летят по сети и отъедают пропускную способность канала, > это обстоятельство может навредить желанию загрузить все причандалы > к странице побыстрее. > > Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю > профит от сложной и очень тяжёлой технологии". И push в том ряду. > http2 решает искуственную проблему - у браузера по каким-то странным причинам ограничего количество одновременных tcp сессий, обычно двумя сессиями. И, допустим, браузер параллельно тащит два оочень медленных ответа, все остальные элементы, как то css стили, которые нужны для того, чтобы отрендерить страницу, на паузе. т.е. браузер решил сам себе ограничить количество сессий - удачи ему. а потом пришли разработчики http2 и сказали "а давайте внутри одной tcp сессии будет типа еще один инкапсулированный tcp с мультиплексированием". ну то есть нам дорого открыть несколько честных tcp потоков, лучше мы заморочимся тем, что будем мультиплексировать tcp внутри tcp. насчет действительно связанных css и js - в принципе можно их эмбедить прямо в html разметку. и отдавать вместе с основной страницей. тот же push. > -- > Eugene Berdnikov > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote: > Но предполагаю, что клиенту отказаться от push'а проще, чем сделать > дополнительный запрос к ресурсу. Если клиент умеет cache digest, то да, может отказаться заранее. А если нет, то к тому моменту, когда клиент сможет отклонить push, данные уже летят по сети и отъедают пропускную способность канала, это обстоятельство может навредить желанию загрузить все причандалы к странице побыстрее. Вообще, почти про всё связанное с http2 можно сказать "близкий к нулю профит от сложной и очень тяжёлой технологии". И push в том ряду. -- Eugene Berdnikov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Windows и upstream php-cgi.exe
Hello! On Wed, Apr 29, 2020 at 12:46:23PM -0400, gewisser wrote: > Есть какая-нибудь возможность отправить "Connection: close"? Я об этом писал в самом первом ответе - в конфиге nginx'а выключить keepalive с помощью директивы keepalive_timeout (http://nginx.org/r/keepalive_timeout/ru). -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
> то выигрыш будет отрицательный у меня эта фраза вызывает когнитивный диссонанс On Wed, Apr 29, 2020 at 8:41 PM Илья Шипицин wrote: > > > ср, 29 апр. 2020 г. в 22:26, gz : > >> > > Востребованные ресурсы из push-кэша переходят в основной и будут >> > > использованы для следующих страниц. >> > > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся >> > в >> > > кэше. >> > > В крайнем случае несложно пометить клиента стандартным способом >> > через >> > > cookie. >> > >> > Проблема в том, что даже отказ от push-ресурсов - это нагрузка как >> > на сервер, так и на канал. И статистика как бы говорит нам, что в >> > среднем эти накладные расходы - больше, чем польза. >> >> Я таковой статистикой не располагаю. >> Но предполагаю, что клиенту отказаться от push'а проще, чем сделать >> дополнительный запрос к ресурсу. >> >> > Что будет конкретно в вашем случае - зависит, безусловно, от >> > конкретной нагрузки и от того, насколько "в крайнем случае >> > несложно" вам будет избежать лишних push'ей. Но, повторюсь, в >> > среднем - будет хуже, потому что "в крайнем случае" никто не >> > заморачивается. Именно поэтому я начал с вопроса пробовали ли вы >> > тестировать, что получится. Подозреваю, что от банального >> > перекладывания существующих в push'ы - >> > станет только хуже. >> >> Да, я понял Вашу точку зрения. >> Да, узкого эксперимента я не проводил. >> >> > >> >> https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf >> > > >> > > Не совсем понимаю какие выводы делают авторы. >> > > >> > > Предлагают работать над приоритезацией (которая и так корректная, и >> > > регулируется preload'ом), использовать экспериментальный QUIC, >> > поддержики >> > > которого толком нет. >> > >> > Авторы ясно и однозначно показывают, что server push - в среднем >> > вредит, и в большинстве случаев лишь способ выстрелить себе в >> > ногу. И предлагают работать над другими технологиями, >> > потенциально более полезными. >> > >> > Тут важно понимать, что речь идёт про взгляд разработчиков >> > браузера, и рассказывалось это всё на HTTP working group, то есть >> > в рамках встречи людей, занимающихся разработкой протокола. >> >> Из Ваших соображений и трактовке вышеприведённого исследования >> складывается >> впечатление, что даже разработчики протокола не донца понимают зачем push >> нужен. >> При том, что не только они описали его в протоколе, но и сторонние >> разработчики реализовали поддержку push'а клиентах и нескольких серверах. >> >> > (Ну и да, про приоритезацию - смешно. Нет, это не про preload, >> > это, как я понимаю, про приоритеты в рамках HTTP/2. Там самолёт с >> > бассейном и джакузи запроектирован в рамках стандарта, корректности >> > ждать не приходится.) >> >> Я о текущей примитивной приоретизации. >> Сомневаюсь, что когда-нибудь появятся инстументы точного управления ею, >> браузеры всё равно будут вынуждены использовать указания как рекомендацию. >> >> > > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на >> > практике >> > > проталкивание критических ресурсов, которые в любом случае >> > приоритетны и >> > > будут загружены для отрисовки. >> > >> > Именно с этого я и начал: попробуйте на практике на отдельных >> > страницах, без попыток вытаскивать версии ресурсов через SSI и вот >> > этого всего. Получите статистику, сравните. >> > >> > Сейчас же вы пришли и убеждаете разработчиков, что вам надо, >> > потому что оно точно будет лучше, но тестировать вы ничего не >> > тестировали и не хотите. >> >> Где именно и кого я в чём-то убеждал и убеждал в том, что мне нужно? >> Я задал вопрос о планах. >> >> А учитывая, что использовать саму директиву http2_push затруднительно — >> один >> ресурс за раз, невозможность использования в if — и предвидя рекомендацию >> использовать http2_push_preload, я рассказал о том, в какую сторону пошёл >> и >> что уже попробовал сделать своими силами, и о том, какие возможности могли >> бы помочь в решении задачи. >> >> > Так это не работает. Придёте со >> > стастикой, явно показывающей плюсы - мы задумаемся над тем, как >> > облегчить вам жизнь в конфигурации с SSI. Пока же из статистике >> > есть вот только ссылка выше, из которой явно следует, что делать >> > что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно. >> >> То, о чём я рассказываю и есть эксперимент. >> Проще внедрить это на dev- или даже production-версии сайта, чем готовить >> узкие эксперименты из двух страниц. >> > > у вас же должны быть логи по html страницам и по css-файлам. посмотрите на > них. > если > > а) у вас хорошее кеширование (т.е. ноль 304-х) > б) количество ответов css соответствует количеству отданных html страниц > > то, вероятно, в вашем случае будет профит от того, что сделаете push на css > ну и наоборот, если css отдается меньше, или отдается столько же, но много > 304-х, > то выигрыш будет отрицательный > > > >> В случае pdocution'а можно прогнозировать значимое изменение в статистике >> загрузки страниц, в том
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
ср, 29 апр. 2020 г. в 22:26, gz : > > > Востребованные ресурсы из push-кэша переходят в основной и будут > > > использованы для следующих страниц. > > > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся > > в > > > кэше. > > > В крайнем случае несложно пометить клиента стандартным способом > > через > > > cookie. > > > > Проблема в том, что даже отказ от push-ресурсов - это нагрузка как > > на сервер, так и на канал. И статистика как бы говорит нам, что в > > среднем эти накладные расходы - больше, чем польза. > > Я таковой статистикой не располагаю. > Но предполагаю, что клиенту отказаться от push'а проще, чем сделать > дополнительный запрос к ресурсу. > > > Что будет конкретно в вашем случае - зависит, безусловно, от > > конкретной нагрузки и от того, насколько "в крайнем случае > > несложно" вам будет избежать лишних push'ей. Но, повторюсь, в > > среднем - будет хуже, потому что "в крайнем случае" никто не > > заморачивается. Именно поэтому я начал с вопроса пробовали ли вы > > тестировать, что получится. Подозреваю, что от банального > > перекладывания существующих в push'ы - > > станет только хуже. > > Да, я понял Вашу точку зрения. > Да, узкого эксперимента я не проводил. > > > > > https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf > > > > > > Не совсем понимаю какие выводы делают авторы. > > > > > > Предлагают работать над приоритезацией (которая и так корректная, и > > > регулируется preload'ом), использовать экспериментальный QUIC, > > поддержики > > > которого толком нет. > > > > Авторы ясно и однозначно показывают, что server push - в среднем > > вредит, и в большинстве случаев лишь способ выстрелить себе в > > ногу. И предлагают работать над другими технологиями, > > потенциально более полезными. > > > > Тут важно понимать, что речь идёт про взгляд разработчиков > > браузера, и рассказывалось это всё на HTTP working group, то есть > > в рамках встречи людей, занимающихся разработкой протокола. > > Из Ваших соображений и трактовке вышеприведённого исследования складывается > впечатление, что даже разработчики протокола не донца понимают зачем push > нужен. > При том, что не только они описали его в протоколе, но и сторонние > разработчики реализовали поддержку push'а клиентах и нескольких серверах. > > > (Ну и да, про приоритезацию - смешно. Нет, это не про preload, > > это, как я понимаю, про приоритеты в рамках HTTP/2. Там самолёт с > > бассейном и джакузи запроектирован в рамках стандарта, корректности > > ждать не приходится.) > > Я о текущей примитивной приоретизации. > Сомневаюсь, что когда-нибудь появятся инстументы точного управления ею, > браузеры всё равно будут вынуждены использовать указания как рекомендацию. > > > > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на > > практике > > > проталкивание критических ресурсов, которые в любом случае > > приоритетны и > > > будут загружены для отрисовки. > > > > Именно с этого я и начал: попробуйте на практике на отдельных > > страницах, без попыток вытаскивать версии ресурсов через SSI и вот > > этого всего. Получите статистику, сравните. > > > > Сейчас же вы пришли и убеждаете разработчиков, что вам надо, > > потому что оно точно будет лучше, но тестировать вы ничего не > > тестировали и не хотите. > > Где именно и кого я в чём-то убеждал и убеждал в том, что мне нужно? > Я задал вопрос о планах. > > А учитывая, что использовать саму директиву http2_push затруднительно — > один > ресурс за раз, невозможность использования в if — и предвидя рекомендацию > использовать http2_push_preload, я рассказал о том, в какую сторону пошёл и > что уже попробовал сделать своими силами, и о том, какие возможности могли > бы помочь в решении задачи. > > > Так это не работает. Придёте со > > стастикой, явно показывающей плюсы - мы задумаемся над тем, как > > облегчить вам жизнь в конфигурации с SSI. Пока же из статистике > > есть вот только ссылка выше, из которой явно следует, что делать > > что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно. > > То, о чём я рассказываю и есть эксперимент. > Проще внедрить это на dev- или даже production-версии сайта, чем готовить > узкие эксперименты из двух страниц. > у вас же должны быть логи по html страницам и по css-файлам. посмотрите на них. если а) у вас хорошее кеширование (т.е. ноль 304-х) б) количество ответов css соответствует количеству отданных html страниц то, вероятно, в вашем случае будет профит от того, что сделаете push на css ну и наоборот, если css отдается меньше, или отдается столько же, но много 304-х, то выигрыш будет отрицательный > В случае pdocution'а можно прогнозировать значимое изменение в статистике > загрузки страниц, в том числе по данным браузеров — в той же Метрике, > Google > Console или PageSpeed Insights. > > Простой эксперимент, конечно, имеет право на жизнь, но это пара страниц и > несколько доступных браузеров и инструментов. > > Posted at Nginx Forum: >
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
> > Востребованные ресурсы из push-кэша переходят в основной и будут > > использованы для следующих страниц. > > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся > в > > кэше. > > В крайнем случае несложно пометить клиента стандартным способом > через > > cookie. > > Проблема в том, что даже отказ от push-ресурсов - это нагрузка как > на сервер, так и на канал. И статистика как бы говорит нам, что в > среднем эти накладные расходы - больше, чем польза. Я таковой статистикой не располагаю. Но предполагаю, что клиенту отказаться от push'а проще, чем сделать дополнительный запрос к ресурсу. > Что будет конкретно в вашем случае - зависит, безусловно, от > конкретной нагрузки и от того, насколько "в крайнем случае > несложно" вам будет избежать лишних push'ей. Но, повторюсь, в > среднем - будет хуже, потому что "в крайнем случае" никто не > заморачивается. Именно поэтому я начал с вопроса пробовали ли вы > тестировать, что получится. Подозреваю, что от банального > перекладывания существующих в push'ы - > станет только хуже. Да, я понял Вашу точку зрения. Да, узкого эксперимента я не проводил. > https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf > > > > Не совсем понимаю какие выводы делают авторы. > > > > Предлагают работать над приоритезацией (которая и так корректная, и > > регулируется preload'ом), использовать экспериментальный QUIC, > поддержики > > которого толком нет. > > Авторы ясно и однозначно показывают, что server push - в среднем > вредит, и в большинстве случаев лишь способ выстрелить себе в > ногу. И предлагают работать над другими технологиями, > потенциально более полезными. > > Тут важно понимать, что речь идёт про взгляд разработчиков > браузера, и рассказывалось это всё на HTTP working group, то есть > в рамках встречи людей, занимающихся разработкой протокола. Из Ваших соображений и трактовке вышеприведённого исследования складывается впечатление, что даже разработчики протокола не донца понимают зачем push нужен. При том, что не только они описали его в протоколе, но и сторонние разработчики реализовали поддержку push'а клиентах и нескольких серверах. > (Ну и да, про приоритезацию - смешно. Нет, это не про preload, > это, как я понимаю, про приоритеты в рамках HTTP/2. Там самолёт с > бассейном и джакузи запроектирован в рамках стандарта, корректности > ждать не приходится.) Я о текущей примитивной приоретизации. Сомневаюсь, что когда-нибудь появятся инстументы точного управления ею, браузеры всё равно будут вынуждены использовать указания как рекомендацию. > > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на > практике > > проталкивание критических ресурсов, которые в любом случае > приоритетны и > > будут загружены для отрисовки. > > Именно с этого я и начал: попробуйте на практике на отдельных > страницах, без попыток вытаскивать версии ресурсов через SSI и вот > этого всего. Получите статистику, сравните. > > Сейчас же вы пришли и убеждаете разработчиков, что вам надо, > потому что оно точно будет лучше, но тестировать вы ничего не > тестировали и не хотите. Где именно и кого я в чём-то убеждал и убеждал в том, что мне нужно? Я задал вопрос о планах. А учитывая, что использовать саму директиву http2_push затруднительно — один ресурс за раз, невозможность использования в if — и предвидя рекомендацию использовать http2_push_preload, я рассказал о том, в какую сторону пошёл и что уже попробовал сделать своими силами, и о том, какие возможности могли бы помочь в решении задачи. > Так это не работает. Придёте со > стастикой, явно показывающей плюсы - мы задумаемся над тем, как > облегчить вам жизнь в конфигурации с SSI. Пока же из статистике > есть вот только ссылка выше, из которой явно следует, что делать > что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно. То, о чём я рассказываю и есть эксперимент. Проще внедрить это на dev- или даже production-версии сайта, чем готовить узкие эксперименты из двух страниц. В случае pdocution'а можно прогнозировать значимое изменение в статистике загрузки страниц, в том числе по данным браузеров — в той же Метрике, Google Console или PageSpeed Insights. Простой эксперимент, конечно, имеет право на жизнь, но это пара страниц и несколько доступных браузеров и инструментов. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,287886#msg-287886 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
> Советую смотреть не на куки, а на наличия клиенских заголовков - > If-None-Match и/или If-Modified-Since, только при отсутствии или не > валидности данных заголовков делать push. > Из нашего опыта - push полезен только для клиентов у которых нет > валидного кеша, в этом случаи вы получите не большой прирост в > скорости около 5-10%. Не совсем понимаю Ваш совет. Решение о push'е принимается при генерации HTML-ответа за запрос к странице. В этот момент доступны If-None-Match и/или If-Modified-Since только самой страницы и странно ориентироваться на них, так как они ничего не говорят о наличии в кэше клиента тех ресурсов, которые мы планируем протолкнуть в ответе. А если поступит conditional-get-запрос к самому ресурсу, то что-либо делать с push'ем уже поздно. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,287887#msg-287887 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Windows и upstream php-cgi.exe
Есть какая-нибудь возможность отправить "Connection: close"? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287560,287884#msg-287884 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
