The OpenNET Project / Index page

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

Релиз http-сервера lighttpd 1.4.29

04.07.2011 09:31

После 10 месяцев разработки увидел свет релиз легковесного http-сервера lighttpd 1.4.29. Релиз носит корректирующий характер и содержит 11 исправлений, из которых можно отметить:

  • Устранен конфликт встроенных md5-функций с их аналогами из состава OpenSSL, встроенные функции теперь снабжены префиксом "li_";
  • Улучшение поддержки SSL, реализованы алгоритмы обмена ключами Diffie-Hellman и Elliptic-Curve Diffie-Hellman, а также поддержка ssl.use-sslv3;
  • На платформе Solaris реализован fdevent-обработчик "solaris-eventports".
  • Решена проблема с ожиданием ответа в mod_proxy, даже если заголовок content-length равен нулю;
  • В лог больше не выводятся вводящие в заблуждение сообщения "connection closed: poll() -> ERR";
  • В mod_cgi буфер чтения адаптируется под большие блоки входных данных;
  • Налажено определение в процессе сборки библиотеки libev;
  • Устранены проблемы при попытке сборки без поддержки SSL;
  • При обработке CGI-скриптов в переменной окружения DOCUMENT_ROOT теперь указывается реальная базовая директория.


  1. Главная ссылка к новости (http://www.lighttpd.net/2011/7...)
  2. OpenNews: Вышел корректирующий релиз http-сервера lighttpd 1.4.28
  3. OpenNews: Вышел корректирующий релиз http-сервера lighttpd 1.4.27
  4. OpenNews: Вышел релиз http-сервера lighttpd 1.4.26 с исправлением DoS уязвимости
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/31074-lighttpd
Ключевые слова: lighttpd, http
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (28) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 10:31, 04/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    есть тенденция ухода на nginx, статистика против lighttpd
     
     
  • 2.7, tmp (?), 11:52, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > есть тенденция ухода на nginx, статистика против lighttpd

    Есть тенденция костылирования apache с помощью nginx.

     
     
  • 3.8, Hety (??), 11:56, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Не скажите. Во многих случаях апач смысла нет использовать. Связки nginx + php-fpm хватает для большинства проектов на пыхе.
     
     
  • 4.10, frad00r4 (?), 12:05, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    если переключить apache в worker, то про больших нагрузках он обрабатывает большее количество чем php-fpm, причём значительно больше
     
     
  • 5.20, nikll (ok), 16:48, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    да ну!!! откуда такие данные то? а ты пробовал php-fpm настривать?
     
  • 5.21, Sylvia (ok), 20:08, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    это еще смотря что называть большими нагрузками, и смотря сколько на сервере ресурсов, так конечно mod_php изначально немножко быстрее работает (хотя для php 5.4 это уже спорно)
     
  • 5.24, Аноним (-), 21:58, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > если переключить apache в worker, то про больших нагрузках он обрабатывает большее
    > количество чем php-fpm, причём значительно больше

    А результатами бенчмарков поделитесь? Хочется на это "значительно" посмотреть.

     
  • 4.22, Sylvia (ok), 20:09, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > php-fpm хватает для большинства проектов на пыхе.

    при наличии нормального администратора и как минимум хоста уровня vps, в "общагах" как был апач, так и будет

     
     
  • 5.25, Аноним (-), 22:01, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > как был апач, так и будет

    И хакать всю ораву помоечных котов при дырявости одного - как хакали, так и будут. Прикольно когда сайт крупной конторки оказывается поломан просто потому что угораздило же - висел рядом с дырявым сайтом пионера. Шареды - маздайная технология по определению :P.

     
     
  • 6.27, 1 (??), 11:17, 05/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    сколько хакнул ты?
     
  • 2.11, Аноним (-), 12:49, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > есть тенденция ухода на nginx, статистика против lighttpd

    Ухода с апача на nginx, да :). И немного на лайт, но на нжинкс - больше. Что не мешает апачу повышать рыночную долю за счет дутых сайтов без контента и юзеров :)

     

  • 1.2, Аноним (-), 10:35, 04/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    а ктонить и фронтов поддерживает хттп 1.1 и кипалив до бэка?
     
     
  • 2.3, Аноним (-), 10:46, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ничего не понял.
     
     
  • 3.5, Аноним (-), 11:26, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    сейчас, что энжи, что лайти, на бэки ходят по хттп 1.0
    т.е. на каждый новый запрос, открывается коннект, и погнали на бэк.
    даже если на фронт хттп 1.1 запрос пришел и с кипаливом.
    так вот собственно и вопрос: какой из фронтов умеет поддерживать соединения до бэков и не прибивать их.

    для примера возмите энжи, страничку из 10-ти мемкэш сси-вставок и посмотрите время генерации. ну там ab -n 10000.
    потом прикрутите модуль upstream_keepalive и опять посмотрите.
    проблема в том что этот модуль сейчас не работает с хттп(

     
     
  • 4.6, Жирный ублюдок DBA (?), 11:36, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > сейчас, что энжи, что лайти, на бэки ходят по хттп 1.0
    > т.е. на каждый новый запрос, открывается коннект, и погнали на бэк.
    > даже если на фронт хттп 1.1 запрос пришел и с кипаливом.
    > так вот собственно и вопрос: какой из фронтов умеет поддерживать соединения до
    > бэков и не прибивать их.
    > для примера возмите энжи, страничку из 10-ти мемкэш сси-вставок и посмотрите время
    > генерации. ну там ab -n 10000.
    > потом прикрутите модуль upstream_keepalive и опять посмотрите.
    > проблема в том что этот модуль сейчас не работает с хттп(

    Вот тот же вопрос. Очень страдаю из за того что в nginx этого нет.
    Есть проект apache traffic, там помоему есть поддержка.
    Интересно твое мнение по этому продукту.


     
     
  • 5.19, Аноним (-), 15:08, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот тот же вопрос. Очень страдаю из за того что в nginx
    > этого нет.
    > Есть проект apache traffic, там помоему есть поддержка.
    > Интересно твое мнение по этому продукту.

    нещюпал. по первым прикидкам интересно. но как-то сравнений в производительности-фичах не было статеек. самостоятельно пока нет времени тестировать. хотя да, говорят яху на нем ездит.

     
     
  • 6.28, o (?), 00:45, 06/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Как раз щупаю ATS. Что то нет там ничего для фронтенда. Ни keepalive ни upsteam балансировки.
    Балансировка тока по regexp url. Походу ATS это прокси и все. Крутой такой прокси.

    Может я криво смотрел, если кто скажет как там реализовать что то похожее на upstream в nginx?

     
  • 4.12, Аноним (-), 12:56, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > сейчас, что энжи, что лайти, на бэки ходят по хттп 1.0

    Use fastcgi, Luke.

     
     
  • 5.16, Аноним (-), 13:37, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> сейчас, что энжи, что лайти, на бэки ходят по хттп 1.0
    > Use fastcgi, Luke.

    есть прокся нормальная? которая работает как fcgi и на бэки ходит сама как 1.1?
    имя сестра! имя! (С) )

     
     
  • 6.17, Andrey Mitrofanov (?), 14:27, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>> сейчас, что энжи, что лайти, на бэки ходят по хттп 1.0
    >> Use fastcgi, Luke.
    > есть прокся нормальная? которая работает как fcgi и на бэки ходит сама
    > как 1.1?

    Может быть, он имел в виду ходить на fcgi прямо из энджиникса, как "доктор прописал"?

    И нет, там, вроде, нет ничего, кроме, одна ссессия на fcgi на один документ.

    Интересно, зачем _так_ нужен именно 1.1 ? _Такие_ большие накладные расходы на открытие tcp соединения?

     
     
  • 7.18, Аноним (-), 15:06, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно, зачем _так_ нужен именно 1.1 ? _Такие_ большие накладные расходы на
    > открытие tcp соединения?

    выше было предложение проверить самостоятельно с помощью энжи,мемкэша и странички из 10-ти вставок.
    на самом деле когда обратываются миллионы запросов на паре-тройке фронтов и пучке бэков, такой нюанс как время на соединение-разъединение начинает проявляться достаточно активно.

     
     
  • 8.26, Andrey Mitrofanov (?), 10:18, 05/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    На страничке из 10 вставок , да, время соединения -- самое важное, над чем можн... текст свёрнут, показать
     
  • 7.23, Sylvia (ok), 20:11, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно, зачем _так_ нужен именно 1.1 ? _Такие_ большие накладные расходы на
    > открытие tcp соединения?

    или вообще сокет )

     
  • 2.9, Гений. (?), 12:04, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Varnish умеет.
     
     
  • 3.14, Аноним (-), 13:35, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Varnish умеет.

    спасибо. вроде умеет. по производительности в статике как? переход с энжи тяжол ли?

     

  • 1.4, Аноним (4), 10:56, 04/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а у кого нибудь получилось собрать с --with-openssl без примерно такой ошибки http://redmine.lighttpd.net/boards/2/topics/4335 ?
     
     
  • 2.13, XVilka (ok), 13:05, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    EC - Elliptic Curve. Проверьте версию OpenSSL. Он должен быть не ниже 1.0 для поддержки эллиптического шифрования.
     
     
  • 3.15, Аноним (4), 13:35, 04/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    версия 1.0.0d

    rpm -qa | grep openssl
    openssl-devel-1.0.0d-1.fc14.x86_64
    openssl-1.0.0d-1.fc14.x86_64

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



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

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