The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск nginx 1.27.3

26.11.2024 22:30

Представлен выпуск основной ветки nginx 1.27.3, в рамках которой продолжается развитие новых возможностей. В параллельно поддерживаемой стабильной ветке 1.26.x вносятся только изменения, связанные с устранением серьёзных ошибок и уязвимостей. В дальнейшем на базе основной ветки 1.27.x будет сформирована стабильная ветка 1.28. Код проекта написан на языке Си и распространяется под лицензией BSD.

Среди изменений:

  • В директиву "server", используемую в блоке "upstream", добавлена поддержка параметра "resolve", включающего отслеживание изменения IP-адреса для используемого доменного имени и автоматическое обновление конфигурации блока "upstream" без необходимости перезапуска nginx в случае изменения адреса.
  • В модуль ngx_mail_proxy_module добавлена поддержка специфичного для SmarterMail режима IMAP LOGIN с нетегированным ответом CAPABILITY.
  • По умолчанию отключены протоколы TLSv1 и TLSv1.1.
  • В директивах "proxy_bind", "fastcgi_bind", "grpc_bind", "memcached_bind", "scgi_bind" и "uwsgi_bind", а также в качестве адреса клиента в модуле ngx_http_realip_module разрешено указание IPv6-адресов в квадратных скобках без номера порта.
  • Устранены ошибки в реализациях модуля ngx_http_mp4_module и директивы "proxy_store".
  • На платформе DragonFly BSD налажена работа параметра so_keepalive в директиве listen.


  1. Главная ссылка к новости (https://mailman.nginx.org/pipe...)
  2. OpenNews: Выпуск nginx 1.27.2
  3. OpenNews: Выпуск Angie 1.7.0, форка Nginx
  4. OpenNews: Проект Nginx перевёл разработку на Git и GitHub
  5. OpenNews: Представлен FreeNginx, форк Nginx, созданный из-за несогласия с политикой компании F5
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/62298-nginx
Ключевые слова: nginx
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (10) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.3, Hippopotamus (ok), 00:03, 27/11/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    До чего же достали его проблемы с ДНС. Это же просто фича номер 1 - ты уважаешь отданный тебе TTL. И не просишь указать всякие там resolver, потому что ты используешь libnss... Не могу просто, злюсь п..ц
    П.с. фиксить это сам я конечно не буду
     
     
  • 2.6, Ilya Evseev (?), 00:41, 27/11/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    libnss блокирующая или асинхронная?
    Если Сысоев стал писать встроенный ресолвер - то скорее первое.
    Из-за этого nginx её использует только при парсинге конфига.
     
     
  • 3.7, morphe (?), 00:44, 27/11/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > libnss блокирующая или асинхронная?

    Для задач nginx можно поднять для такого отдельный поток, и асинхронно лишь ждать ответа от него

     
     
  • 4.17, Ilya Evseev (?), 09:25, 27/11/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >> libnss блокирующая или асинхронная?
    > Для задач nginx можно поднять для такого отдельный поток, и асинхронно лишь
    > ждать ответа от него

    И любой медленный ответ будет тормозить всю очередь запросов.


     
     
  • 5.22, morphe (?), 23:34, 27/11/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>> libnss блокирующая или асинхронная?
    >> Для задач nginx можно поднять для такого отдельный поток, и асинхронно лишь
    >> ждать ответа от него
    > И любой медленный ответ будет тормозить всю очередь запросов.

    Так ли это важно для DNS?

     
     
  • 6.23, Аноним (-), 09:35, 28/11/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Так ли это важно для DNS?

    Это очень важно.

    Мы говорим про прокси сервер, через который пролетает масса запросов к разным доменам. Прокси должен эти домены резолвить. Если к тебе прилетело 100 запросов, и ты в один поток резолвишь, и первый же запрос к DNS серверу занял 5 секунд, то все твои 100 запросов будут стоять и ждать эти 5 секунд. Все кроме первого продолжат ждать, когда первый DNS запрос наконец получит ответ.

     
     
  • 7.27, morphe (?), 18:46, 28/11/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Мы говорим про прокси сервер, через который пролетает масса запросов к разным
    > доменам. Прокси должен эти домены резолвить.

    Когда речь идёт про nginx, DNS используется в качестве service discovery, а не рекурсивный (Если есть юзкейсы для резолва third-party - в студию), и это не нормально если service discovery занимает 5 секунд

    Но даже если и так, то почему бы и нет, если результаты DNS кешируются, и это только самый первый запрос к домену столько займёт? Тем более что резолвить можно не лениво

     
  • 3.30, Сталин (?), 16:10, 29/11/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Сывоев давно ушёл из nginx
     

  • 1.18, Аноним (18), 11:06, 27/11/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Устранены ошибки в реализациях модуля ngx_http_mp4_module

    шо, опять? Или это скопипасчены секьюрити фиксы из форков?

     
  • 1.29, Аноним (29), 14:04, 29/11/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    когда оно уже научиться легко и быстро из коробки https3?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру