Увидел свет (http://www.lighttpd.net/2014/3/12/1.4.35/) релиз легковесного http-сервера lighttpd 1.4.35 (http://www.lighttpd.net). Выпуск носит корректирующий характер и содержит около двадцати изменений. Отдельно отмечается устранение уязвимости (http://download.lighttpd.net/lighttpd/security/lighttpd_sa_2...), которая проявляется при использовании модуля mod_mysql_vhost и может привести к подстановке SQL-кода через передачу специально оформленного содержимого HTTP-заголовка "Host:" (например, "Host: [::1]' UNION SELECT '/") из-за некорректной проверки IPv6 адресов.Уязвимость также присутствует в модулях mod_evhost и mod_simple_vhost и позволяет выйти за пределы текущей директории при указании ".." в пути, но проявляется только при наличии директорий с символами "[]", что делает уязвимость неприменимой на практике (например при наличии маски evhost.path-pattern = "/var/www/%0/" указание в поле "Host:" имени "[]/../../../" может привести к выходу за пределы /var/www/ при наличии директории /var/www/[]/).
Кроме уязвимостей в новом выпуске устранена порция выявленных в процесcе тестирования в scan.coverity.com проблем, связанных с некорректной работой с буферами, утечками памяти и обращением к уже освобождённым областям памяти.
URL: http://www.lighttpd.net/2014/3/12/1.4.35/
Новость: http://www.opennet.me/opennews/art.shtml?num=39310
Стоит использовать вместо апача?
Только если используются CGI-скрипты. Во всех остальных случаях - nginx.
А чотак? nginx не умеет CGI? Или Lighttpd не умеет чего-то, что умеет nginx?
> А чотак? nginx не умеет CGI? Или Lighttpd не умеет чего-то, что умеет nginx?Да, nginx не умеет CGI. Впрочем, CGI сейчас мало где используется. Во всём остальном nginx не уступает или превосходит Lighttpd.
Дык тот-же PHP у них PHP-FPM, который чрез FastCGI.
FastCGI != CGI
> Стоит использовать вместо апача?Нет. Используйте Apache.
> Нет. Используйте Apache....если денег на крЮтые серваки не жалко, особенно для сервировки статики.
Вместо апача у многих уже nginx.
nginx используют как балансирующий прокси для фермы апачей.
Если мод-перл, да. Все остальное проще с точки зрения конфигурирования и экономнее по потреблению памяти запускать через fastcgi/scgi/wsgi.В последний раз живой апач видел в 2008-м году, щас уже и не вспомню, как его настраивать.
> не вспомню, как его настраиватьМожет, твоя проблема была в этом?
> Может, твоя проблема была в этом?Учитывая политику апача - они могут идти на йух. Нормально сервировать статику они можно считать что не умеют, конфигурация замороченная, на динамике тоже ничего интересного не демонстрируют. Зато бзики по всякой энтерпрайзятине на яве им мозг сожрали. Ну и ориентируются на энтерпрайзы с серверами по 128 гигз памяти и 64 ядрами. Если у вас не дай боже сервак слабее, его школьник с мобилки сможет уронить.
> Учитывая политику апача - они могут идти на йух.Учитывая нежелание nginx поддерживать htaccess - они могут идти туда же.
> Если у вас не дай боже сервак слабее, его школьник с мобилки сможет уронить.
Для этого нужен не только слабый сервак, но убунтенок-эникей вместо админа (которые вообще не знает, что такое настройка параметров и нагрузочное тестирование).
> Учитывая нежелание nginx поддерживать htaccessне понимаю, какая проблема сделать себе эту чушь, если без неё никак оргазм не получается.
Я немного утрировал, не понадобилось все это время ни разу, но в общих чертах помню (о, этот ад с Directory/Location, это незабываемо), хотя за это время, конечно, многое изменилось - видел издалека и офигел с числа модулей в дефолтной сборке современного апача.Недавно вот имел дело (о ужас!) с windows server, вполне справился, хотя в последний раз его видел в 2003-м году. Поразился, что современные виндоадмины не знают даже базовых консольных виндовых команд, типа netsh и sc.
> (о, этот ад с Directory/Location, это незабываемо),Насколько я помню, в этом nginx практически не отличается от apache.
> офигел с числа модулей в дефолтной сборке современного апача.
Это безусловный плюс апача - не надо делать кастомные пересборки на каждый чих.
> не надо делать кастомные пересборки на каждый чих.бедняга. я тебе сейчас радостную новость поведаю: сишный код давно уже не надо ручками в машинный переводить, это автоматизировали.
Всегда поражаюсь такому. Почему в подобных модулях (в том числе многих ftp и dns-серверах) не используют prepared statements? Это ведь намного выгоднее - один раз после соединения сделать prepare, а дальше долбить execute по уже распарсенному и спланированному запросу. Не говоря уж о безопасности.
индусы потому что
в принципе, потому, что «мускульвхост» нафиг никому особо не упёрся. написали как получилось и забыли.