После года разработки представлена (http://nginx.org/?1.16) новая стабильная ветка высокопроизводительного HTTP-сервера и многопротокольного прокси-сервера nginx 1.16.0 (http://nginx.org/), которая вобрала в себя изменения, накопленные в рамках основной ветки 1.15.x. В дальнейшем все изменения в стабильной ветке 1.16 будут связаны с устранением серьёзных ошибок и уязвимостей. В скором времени будет сформирована основная ветка nginx 1.17, в рамках которой будет продолжено развитие новых возможностей. Для обычных пользователей, у которых нет задачи обеспечить совместимость со сторонними модулями, рекомендуется (http://nginx.com/blog/nginx-1-6-1-7-released) использовать основную ветку, на базе которой раз в три месяца формируются выпуски коммерческого продукта Nginx Plus.Наиболее заметные улучшения, добавленные в процессе формирования основной ветки 1.15.x:
- Добавлена возможность использования переменных в директивах 'ssl_certificate (https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_...)' и 'ssl_certificate_key (https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_...)', что можно использовать для динамической загрузки сертификатов;- Добавлена возможность загрузки SSL-сертификатов и секретных ключей из переменных без использования промежуточных файлов;
- В блоке "upstream" реализована новая директива "random (http://nginx.org/en/docs/http/ngx_http_upstream_module.html#...)", при помощи которой можно организовать балансировку нагрузки со случайным выбором сервера для проброса соединения;
- В модуль upstream добавлена новая переменная "$upstream_bytes_sent (http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#...)", которая отображает число байт, переданных на сервер группы;- В модуль stream добавлена возможность обработки в рамках одного сеанса нескольких входящих UDP-датаграмм от клиента;
- В модуле ngx_stream_ssl_preread реализована переменная $ssl_preread_protocol (http://nginx.org/en/docs/stream/ngx_stream_ssl_preread_modul...),
которая определяет наибольшую версию протокола SSL/TLS, которую поддерживает клиент. Переменная позволяет создавать конфигурации (https://www.nginx.com/blog/running-non-ssl-protocols-over-ss.../) для доступа с использованием различных протоколов с SSL и без SSL через один сетевой порт при проксировании трафика с использованием модулей http и stream. Например, для организации доступа по SSH и HTTPS через один порт 443 порт по умолчанию можно пробрасывать на SSH, но если определена версия SSL пробрасывать на HTTPS.
- В модуль stream добавлена директива "proxy_requests (http://nginx.org/ru/docs/stream/ngx_stream_proxy_module.html...)", задающее число датаграмм, полученных от клиента, по достижении которого удаляется привязка между клиентом и существующей UDP-сессией. После получения указанного количества датаграмм следующая датаграмма, полученная от того же клиента, начинает новую сессию;
- В директиве listen появилась возможность указания диапазонов портов;- Добавлена директива "ssl_early_data (http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_e...)" для включения режима 0-RTT (https://tools.ietf.org/html/rfc8446#section-2.3) при использовании TLSv1.3, который позволяет сохранить ранее согласованные параметры TLS-соединения и снизить до 2 число RTT при возобновлении ранее установленного соединения;
- Для настройки keepalive для исходящих соединений (включения или выключения опции SO_KEEPALIVE для сокетов) добавлены новые директивы:
- "proxy_socket_keepalive (https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#pr...)" - конфигурирует поведение "TCP keepalive" для исходящих соединений к проксируемому серверу;
- "fastcgi_socket_keepalive (https://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#...)" - конфигурирует поведение "TCP keepalive" для исходящих соединений к FastCGI-серверу;
- "grpc_socket_keepalive (https://nginx.org/ru/docs/http/ngx_http_grpc_module.html#grp...)" - конфигурирует поведение "TCP keepalive" для исходящих соединений к gRPC-серверу;
- "memcached_socket_keepalive (https://nginx.org/ru/docs/http/ngx_http_memcached_module.htm...)" - конфигурирует поведение "TCP keepalive" для исходящих соединений к серверу memcached;
- "scgi_socket_keepalive (https://nginx.org/ru/docs/http/ngx_http_scgi_module.html#scg...)" - конфигурирует поведение "TCP keepalive" для исходящих соединений к SCGI-серверу;
- "uwsgi_socket_keepalive (https://nginx.org/ru/docs/http/ngx_http_uwsgi_module.html#uw...)" - конфигурирует поведение "TCP keepalive" для исходящих соединений к uwsgi-серверу.
- Добавлен новый параметр "delay" в директиве limit_req" (http://nginx.org/ru/docs/http/ngx_http_limit_req_module.html), задающий лимит, по достижении которого избыточные запросы задерживаются;
- В блок upstream" добавлены новые директивы "keepalive_timeout" и "keepalive_requests" для задания лимитов для Keepalive;- Объявлена устаревшей директива "ssl", на смену которой пришёл параметр "ssl" в директиве "listen". Определение отсутствующих SSL-сертификатов теперь производится на этапе тестирования конфигурации при использовании в настройках директивы "listen" с параметром "ssl";
- При использовании директивы reset_timedout_connection при истечении таймаута соединения теперь закрываются с применением кода 444;
- SSL-ошибки "http request", "https proxy request", "unsupported protocol" и "version too low" теперь отображаются в логе с уровнем "info" вместо "crit";
- Добавлена поддержка метода poll на системах Windows при использовании Windows Vista и новее;- Обеспечена возможность использования TLSv1.3 (https://www.opennet.dev/opennews/art.shtml?num=49126) при сборке с библиотекой BoringSSL;
URL: http://mailman.nginx.org/pipermail/nginx-announce/2019/00023...
Новость: https://www.opennet.dev/opennews/art.shtml?num=50561
Нормально так сысоев начал клепать версии, после того как заработал
Да если бы:$ hg log -r 'tag(release-1.15.0)::tag(release-1.16.0)' -T '{author}\n' | sort | uniq -c | sort -nr
111 Maxim Dounin <mdounin@mdounin.ru>
20 Ruslan Ermilov <ru@nginx.com>
17 Sergey Kandaurov <pluknet@nginx.com>
13 Vladimir Homutov <vl@nginx.com>
13 Roman Arutyunyan <arut@nginx.com>
2 Valentin Bartenev <vbart@nginx.com>
2 Maxim Konovalov <maxim@nginx.com>
2 Gena Makhomed <gmm@csdoc.com>
1 Nova DasSarma <nova@novalinium.com>
1 Nikolay Morozov <n.morozov@securitycode.ru>
1 chronolaw <chronolaw@gmail.com>
1 Chanhun Jeong <chanhun.jeong@navercorp.com>
А вот и список копирастов.
Ты ещё наверно в Санта-Клауса веришь? Это всё копирасты наклепали и зондов понаставили. А то что тебе это пытаются теперь втюхать и так радостно это поедаешь означает что они всё правильно сделали.
Да. Лучше и не скажешь (азазаза)
Т.е. то, что код выложен в рид онли моде, тебя все еще не устраивает?
> Т.е. то, что код выложен в рид онли моде, тебя все еще
> не устраивает?И меня не устраивает. http://www.opennet.dev/openforum/vsluhforumID3/40483.html#18
И папу Эрика не устраивает. http://esr.ibiblio.org/?p=8287
И... в кого ни ткни, тоже не устраивает.
Один ты топишь за шкурные интересы шкурных шкур.
Не нравится - не пользуйся. Чего вонять то?
Мне вот не нравится расползание рака GPL, который чего не коснись заражает. Еще и захват средств производства которым пытались диктовать условия (да да, мы все еще помним о той случайной "ошибке" с забытыми исключениями в gcc).Слава богу есть clang который этим не страдает.
> Не нравится - не пользуйся. Чего вонять то?Я, видишь ли, не "про код".
А про пропагандистов и пушеров, как ты.
Сделай вид, что не понял, снова?
> Мне вот не
> Слава богу естьНу, то есть санта-клаус. Ну, лан.
У Вас зонд отклеился
Копирасты минусуют.
Сысоев давно уже другой сервер пилит.
Печаль хороший был продукт.
Добавили бы поддержку логических операторов в if, и цены бы не было.
Игорь всегда говорил, что если ты используешь в конфиге nginx'а if, то значит что-то не так с твоим конфигом и так делать не надо.
Предложи более удобный способ блокировок по заголовкам запроса.
map
ииииии потом IF да ?
Там if используется уже в другом контексте, обычно с return, что законно.
Ну началось.. Речь идет о замене if на map, а не о "тут if можно, а тут нельзя".
map позволяет неудобный список регулярок оформить в одной легко читаемой конструкции и сэкономить ресурсы на обработке запроса. Заменой if'у он не является, увы и ах.
А почему Вам Lua не подходит для скриптования?
Там массивы с 1 начинаются. ННЖНО
Нормальным способом было бы реализовать if или его аналог не на уровне модуля rewrite, а на уровне http_core_module - так, чтобы они были равноправны с location. Ну или расширить сам location, позволив писать дополнительные условия типа location /foo when ($somevar = 1) { ... }.Это неоднократно обсуждалось уже много лет назад, вкратце - слишком много надо переделывать.
с конфигом nginx'а определенно что-то не так - тривиальные вещи требуют нетривиальнейших ухищрений, угадать не заглядывая в код, как работают вложенные конструкции - невозможно (половина if'овых проблем от этого) и т д.зато у нас есть *два* файлика с набором никем и никогда не меняемых настроек для fcgi_proxy - угадайте, почему их два и какой правильный (и почему миллион никем никогда обычно не переопределяемых дефолтов вообще нужно каждый раз include'ом подпихивать в каждый блок с прокси)?
но, поскольку автору оно уже давно неинтересно, он свои дивиденды и так получает, а Максим не революционер, шансов что эту причудливую мешанину заменят вменяемым синтаксисом ровно ноль.
зато, да, давайте завезем в конфиги несколько нескучных язычков, чтоб никому не скучать.
If - да, жуткий костыль, для понимания которого надо знать, в какой последовательности работают какие фазы обработки запроса, и что происходит на фазе rewrite. Это, конечно, ужасно. Тут работает правило "внутри if-а пишем только директивы модуля rewrite" - тогда ничего странного не случится.А с вложенными location-ами надо один раз разобраться с правилами наследования и все становится ясно. Вот хорошая статья на тему: https://blog.martinfjordvald.com/2012/08/understanding-the-n.../
> А с вложенными location-ами надо один раз разобраться с правилами наследования и все становится
> ясностановится ясно что ничего не ясно.
Вот вам из вашего любимого талмуда:The behaviour of a directive is actually entirely up to the module that defines it. All the normal and array directives will inherit properly if they are allowed in that context. For action directives the story is a bit different. Generally they will not inherit into a nested location but it ultimately depends on how the module wants it to be and it can differ on a directive by directive basis.
То есть как работает конкретная команда - "а вот угадай!"
зачем и для чего была понаделана такая неведомая хня вместо иерархического наследования и возможности явно сбросить "array" если вдруг надо (надо крайне редко) - спросите у автора.
Как и почему нельзя нормально пометить директивы в документации, какая из них array, какая не array. (впрочем, это бы не помогло, поскольку всерьез натыкаешься на новые грабли обычно с 3d party модулем, автор которого хорошо если вообще его документировал)
>Объявлена устаревшей директива "ssl", на смену которой пришёл параметр "ssl"посоны-то и не в курсе, что сам SSL давно взломан и устарел.
🤦
а посан-то и не в курсе, что ssl это просто название, а реально протоколы какие сам подключишь, хоть SSL разных версий, хоть различных TLS. =))
Ну наконец tcp keepalive к апстримам появился!
это у кого как. У некоторых, вообще-то появился его выключатель.sysctl net.inet.tcp.always_keepalive
net.inet.tcp.always_keepalive: 1это стандартная настройка.
В оси он у тебя и так был. А вот в nginx не было как класса
> В оси он у тебя и так был. А вот в nginx не было как классачтобы его там "не было как класса" - нужно _специально_ открыть сокет и вручную setsockopt'ом выключить этот режим.
Все почти так, только наоборот. Его как надо явно включить через setsockopt. Иначе его нет.
для бестолковых - вам показали настройку, которая в системе из коробки, и которая делает что он - есть, пока явно не попросишь выключить.
Для совсем бестолковых:
Эта настройка sysctl , что привели ранее, отключает или включает в ядре поддержку tcp keepalive на общесистемном уровне.
Но если вы в своем приложении явно не попросили ядро через setsockopt включить для вашего сокета tcp kerpalive, то его просто так там не образуется и не важно что там в sysctl.Так вот речь в новости о том, что в nginx наконец появилась опция "попросить ядро о tcp kerpalive в сокете к апстриму". Дальше уtcp keepalive в сокете появится или нет в зависимости от того включен ли он на общесистемном уровне.
Жаль что модуль brotli так и не начали строить по умолчанию на FreeBSD. Только из-за этого приходится из портов ставить, а не из пакетов.
Будь мужиком, собери свой пакет!
> Будь мужиком, собери свой пакет!Простите, уже вырос с того возраста ) Сейчас нужен только достаточный результат с минимальными усилиями.
Плиз дайте Алмазы)
Иди уголь долби...
Дайти альмадики))
Я стирав карточки від нової пошти і виграв гелексі самсунг
с10.