Сформирован выпуск основной ветки nginx 1.21.2, в рамках которой продолжается развитие новых возможностей (в параллельно поддерживаемой стабильной ветке 1.20 вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55714
>В новой версии в реализацию Promise добавлены методыДжва года ждал!
> быстрого создания заглушек с решением проблем в web-приложениях.АААААААААААААА!!!! :))))))))))))
:(
Каноничный эксплойт на регэксп таки вроде ааааааааааааааааааа!
Жду интерпретатора nrust
Просто используй Actix
Вроде все же уже с ним ... Ушел разработчик в запой
> ЖдуЭто ты ждун, что ли?
Ооо открытый проприетарный продукт от F5 еще жив...
Зачастили как-то релизы nginx-а...
пора менять версию на 121
Судя по
> Прекращена поддержка экспортного набора шифров.
> Обеспечена блокировка запросов HTTP/1.0, включающих HTTP-заголовок "Transfer-Encoding"они наконец тоже заметили что хакеры умеют даунгрейдить шифры TLS и прикалываться над конвертацией HTTP2 в HTTP1. При том первое они умеют уже много лет.
Сысоев не БЗДун!
> Прекращена поддержка экспортного набора шифров.https://github.com/nginx/nginx/commit/9e4e7a4e4202b5b61b7859...
Export ciphers are forbidden to negotiate in TLS 1.1 and later protocol modes.
They are disabled since OpenSSL 1.0.2g by default unless explicitly configured
with "enable-weak-ssl-ciphers", and completely removed in OpenSSL 1.1.0.
Очень странное решение писать свою реализацию js. Есть же Nginx lua
lua далеко не всем знаком, в js же сейчас только ленивый не умеет
во вторых, lua модуль в nginx от китайцев, а тут ребята хотят сделать более нативный и вписывающийся в концепции nginx
Люди привыкли к браузерному js или nodejs. Тут же нет никакого привычного api и только голый ecmascript. На таком уровне Luna даже проще.
nginx lua - это один большой костыль.Например, файл ngx_http_lua_subrequest.c чуть более чем полностью состоит из копипасты из http-модуля, и по сути дублирует функциональность subrequest-ов из http-модуля с вкраплениями своего кода.
Поскольку все это - не часть инфраструктуры nginx-модулей, а приватное api, с каждым изменением внутри nginx это все ломается, потому там все это обросло еще и пачкой ifdef-ов на версию nginx. Вот, например, прекрасное:
https://github.com/openresty/lua-nginx-module/commit/2b93087...
Я на таком строить production как-то не готов.
При этом можно было бы сказать, что, вот, у nginx такой фиговый api, добавили бы нужное.Однако в njs при решении ровно тех же задач прекрасно обходятся "наследованием" (да, это чистый C, но по смыслу это ООП-шное наследование) от стандартного http-модуля:
https://hg.nginx.org/njs/file/68f8f7ead0fc/nginx/ngx_http_js...
Просто китайцы не очень разобрались в архитектуре nginx.
hg настолько не тормозит, что, оказывается, файлик посмотреть - роботов проверяют.Robots not allowed or you should enable javascript and cookies.
спасибо что не гуглокапча, бжад!!!
Это не hg (там нечему тормозить в этом месте), это снаружи навешанная простейшая защита от ddos. Видимо, были проблемы такого рода.
А дидосили, ясен пень, не просмотром файлика, а запросом diff-ов или stat-ов. Это и в git, и в hg тяжелая операция.
А что мешает nginx inc самим встроить lua, вместо того, чтобы писать ещё одну реализацию js?
Любой встраиваемый язык - это своя виртуальная машина с конечным автоматом, управляемая событиями. Но nginx и есть конечный автомат, управляемый событиями. Пристраивать рядом второй и пытаться их друг с другом подружить - это заведомо неэффективно и костылеобразно.А если уж писать своё, то какая разница, какой язык? JS выбрали как более распространённый.
Lua намного меньше и проще и почти не развивается (что плюс для него). В Js напротив постоянно что-то добавляется, да и легаси много.