Вышел (http://www.lighttpd.net/2012/11/21/1-4-32/) релиз легковесного http-сервера lighttpd 1.4.32. Релиз носит корректирующий характер и содержит 13 исправлений, среди которых устранение уязвимости (http://download.lighttpd.net/lighttpd/security/lighttpd_sa_2...), которая может привести к инициированию отказа в обслуживании удалённым злоумышленником. Уязвимость вызвана ошибкой в коде парсинга HTTP-заголовков и приводит к зависанию процесса из-за бесконечного зацикливания при обработке запроса с определённым образом оформленным заголовком "Connection".
Из не связанных с безопасностью изменений можно отметить:
- Обеспечение поддержки метода PATCH;
- Проведение чистки кода с устранением проблем, выявленных в процессе использования clang/sparse;
- Устранение утечки памяти в коде инициализации сервера;
- Улучшение определения кодирования контента в форматах x-gzip и x-bzip2;
- В mod_extforward обеспечена запись в лог с признаком debug.log-request-handling адресов недоверительных прокси.URL: http://www.lighttpd.net/2012/11/21/1-4-32/
Новость: http://www.opennet.me/opennews/art.shtml?num=35409
Этим еще кто-то пользуется, когда есть nginx?
Вполне нормальный сервак. Им пользуется ряд нагруженных сайтов. Яндекс тот же.А нжинкс тоже неплохая штука, но вот что-что а дырки в нем находят чаще, пожалуй.
> что-что а дырки в нем находят чаще, пожалуй.находят дырки -- это плюс!
(а минус был бы, если дырки там не находили бы. то есть если бы дырки там так и оставались бы не найденными :))
однако Lighttpd помоему более функционально навороченный чем Nginx.
> находят дырки -- это плюс!Кроме случая когда их нашли а вы не пропатчились :)
> однако Lighttpd помоему более функционально навороченный чем Nginx.
Спорный вопрос. Хотя webdav у него получше.
Зато нжинкс много в чем еще в последнее время прокачался и стал довольно разлапистым. А еще у него есть прикольный кэш (можно динамику в статику закешировать). И он не страдает полной буфферизацией ответа бэкэнда. Грубо говоря, если бэкэнд выплюнет iso-sized файл, лайти выжрет прорву памяти на его буферизацию. Нжинкс в такой ситуации себя ведет куда скромнее.
Зачем бэкенду выдавать такие большие файлы?Ну ладно, уговорили, если мне понадобиться это делать, обязательно воспользуюсь nginx.
> Зачем бэкенду выдавать такие большие файлы?Как правило - натурально не требуется. Но во первых, бывают одуревшие скрипты. Во вторых, кому-то может и понадобиться, случаи бывают разные.
> Ну ладно, уговорили, если мне понадобиться это делать, обязательно воспользуюсь nginx.
Ну и правильно. Лайти неплохая штука. С указанным тупняком дизайна вполне можно жить. Ни разу не фатальный недостаток. Так, мелкая неприятная особенность, не более.
Я юзаю и на своей машине для разработки и местами на рабочих серверах.1. в lighttpd fastcgi под нагрузку настраивается очень гибко, а как оно настраивается в nginx смело можно сказать что я не знаю (пробовал и мне не понравилось что через какой-то отдельный вечно отваливающийся shell скрипт надо делать, но люди говорят что я просто до конца не разобрался).
2. при использовании в качестве фронтенда к апачу nginx и fastcgi понопенисуальны - везде одни и те же опции, работают оба шикарно.
> 1. в lighttpd fastcgi под нагрузку настраивается очень гибко,Ага, особенно если бэкэнд сдуреет и отгрузит большую простынку :)
> при использовании в качестве фронтенда к апачу nginx и fastcgi понопенисуальны
Вот только у нжинкса есть кэш, которым при наличии мозга можно динамику в статику кэшировать. И выдерживать ломовые нагрузки на абы каком хламе.
> Ага, особенно если бэкэнд сдуреет и отгрузит большую простынку :)Не понимаю фатализма. lighttpd грохнет бэкенд, в лог напишет backend died и запустит вместо него новый, готовый принимать новое соединение.
> Вот только у нжинкса есть кэш, которым при наличии мозга можно динамику в статику кэшировать.
Здесь ничего не скажу, т.к. не совсем понимаю о чём речь, зачем динамику кешировать, для этого memcached есть. Или это не нужно, или я Вас не так понял, или это действительно нужно и nginx это умеет а lighty - нет, или умеют оба но я об этом не знаю за ненадобностью.
> Не понимаю фатализма. lighttpd грохнет бэкенд, в лог напишет backend died и
> запустит вместо него новый, готовый принимать новое соединение.Нет, пардон. Лайти попробует пхнуть в буфер всю простынку. Если она большая - памяти сожрется немеряно. Это такой тупняк дизайна лайти, он для 1.4.х известен всем, включая разработчиков но его починка требует большой переделки архитектуры и никто это делать не хочет. Были планы исправить в 1.5.х или 2.х, но они ... где? Другое дело что если бэкэнд не отгружает большие портянки (обычно так и есть) то это и не проблема как бы. Но иметь в виду это свойство - следует. А нжинкс перекачивает порциями и не выделяет буфер на всю простыню целиком.
>> Вот только у нжинкса есть кэш, которым при наличии мозга можно динамику в статику кэшировать.
> Здесь ничего не скажу, т.к. не совсем понимаю о чём речь, зачем динамику кешировать,Затем что если страница меняется редко а посетители долбят ее часто - каждый раз ее генерировать без повода - не всегда умно. В этом случае нагрузка от выполнения скрипта может достичь заоблачных высот и при том не иметь никакого смысла: скрипт тысячи раз генерит одно и то же, бессмысленно и беспощадно. Намного лучше если сегенрится 1 раз а потом закешируется и будет лупиться как статика. В таком режиме что угодно выдержит хабраслэшдотчтотамеще эффект. Очень удобный фич. Да, такое применимо с пользой не к любой динамике. Но в некоторых случаях - очень эффективно и даже не ведет к проблемам.
Эталонный пример: вики-подобные страницы. Читают часто. Меняют редко. По поводу чего генерация каждому юзеру путем дерга кучи скрииптов не оправдана.
> для этого memcached есть.
Как бы оперативки обычно сильно меньше чем места на диске и он вообще не о том.
> я Вас не так понял, или это действительно нужно и nginx
> это умеет а lighty - нет, или умеют оба но я об этом не знаю за ненадобностью.Лайти насколько я знаю подобное не умеет в том виде как это сделано в нжинкс, т.е. с автоматическим сохранением в кэш и возможностью обновления кэшированной версии по каким-то условиям типа воемени жизни в кэше.
>> Затем что если страница меняется редко а посетители долбят ее часто - каждый раз ее генерировать без повода - не всегда умно. В этом случае нагрузка от выполнения скрипта может достичь заоблачных высот и при том не иметь никакого смысла: скрипт тысячи раз генерит одно и то же, бессмысленно и беспощадно. Намного лучше если сегенрится 1 раз а потом закешируется и будет лупиться как статика.По-моему, это было понятно всём ещё в 2001 году. Об чём речь-то? И в чём тут фича nginx?
Только не надо говорить про быдло-php.
> И в чём тут фича nginx?Фича в том что он умеет это делать удобно и настраиваемо.
> Только не надо говорить про быдло-php.
Это работает для любого ЯП. PHP в этом плане ничем таким не выделяется, так что ваш батхерт относительно оного совершенно не понятен.
Я пользуюсь. Мне нужно.
Очень, очень нужно сравнение lighttpd и nginx максимум.