Доступен (http://www.apache.org/dist/httpd/Announcement2.4.html) релиз http-сервера Apache 2.4.7 (http://httpd.apache.org), в котором представлено 57 изменений (http://www.apache.org/dist/httpd/CHANGES_2.4.7). Из наиболее важных улучшений отмечается значительное обновление модуля mod_proxy_fcgi, оптимизация производительности Event MPM и улучшение WinNT MPM.Среди изменений:
- Event MPM переведён на использование структуры данных skiplist.
Для сборки Event MPM теперь требуется APR 1.5.0 или более новая версия;- В Unix MPM добавлена реализация ap_mpm_podx_* для исключения дублирования кода и синхронизации с актуальным экспериментальным деревом разработки;
- В mod_proxy_fcgi (http://httpd.apache.org/docs/2.4/mod/mod_proxy_fcgi.html) размер всех закодированных переменных окружения теперь не ограничен 64 Кб, но отдельные переменные не должны превышать 16 Кб. Переработан метод чтения данных, разбитых на несколько пакетов;
- В mod_ssl (http://httpd.apache.org/docs/2.4/mod/mod_ssl.html) улучшена обработка эфемерных ключей DH и ECDH с возможностью определения дополнительных параметров в директиве SSLCertificateFile. Прекращена поддержка шифров экспортного класса с эфемерными ключами, в том числе шифров aNULL, eNULL, EXP. Для работы mod_ssl теперь требуется OpenSSL 0.9.8a или более новая версия;
- Для Windows добавлена экспериментальная поддержка сборки с использованием cmake;- В mod_headers (http://httpd.apache.org/docs/2.4/mod/mod_headers.html) разрешено использование спецификаторов формата в строке подстановки при использовании директивы Header для редактирования заголовков. Добавлена поддержка команды 'setifempty' в директиве Header. Реализован синтаксис 'Header note header-name note-name' для копирования заголовков ответа во внутреннюю переменную;
- В mod_rewrite учтены особенности протокола WebSocket для обеспечения возможности проксирования запроса;
- В mod_auth_basic (http://httpd.apache.org/docs/2.4/mod/mod_auth_basic.html) добавлена директива AuthBasicUseDigestAlgorithm для обеспечения миграции паролей из конфигурации с аутентификацией через mod_auth_digest;- В утилиту ab добавлена опция "-l" для отмены проверки длины ответа;
- В mod_logio (http://httpd.apache.org/docs/2.4/mod/mod_logio.html) добавлена поддержка спецификатора формата "%S", определяющего сумму полученных и отправленных байт;- В mod_filter добавлена поддержка флага "change=no" в директиве FilterProtocol;
Одновременно доступен (http://www.apache.org/dist/httpd/Announcement2.2.html) релиз Apache 2.2.26 в котором отражены (http://www.apache.org/dist/httpd/CHANGES_2.2.26) изменения в mod_ssl и mod_dav.URL: http://www.apache.org/dist/httpd/Announcement2.4.html
Новость: http://www.opennet.me/opennews/art.shtml?num=38505
mod_wsgi так и нет в поставке по-умолчанию? Ну и на фиг тогда он нужен, этот апач? Какой профит его ставить? Ничем же не лучше nginx, а nginx куда быстрее.Словом, обойдусь связкой nginx+gunicorn, а его как не ставил, так ставить и не буду. Пускай его вон любители луа юзают - луашный мод в поставке по-умолчанию идет.
> Пускай его вон любители луа юзают - луашный мод
> в поставке по-умолчанию идет.это явно лучше гвидобейсика будет.
Хм... полагаю, дело не в "лучше-хуже", а в "пользуются-не пользуются". Питоном, как и рубином на рельсах - пользуются. И пользуются многие. И их, если уж на то пошло, куда больше чем тех, кто пользуется луа. А здравый смысл говорит, что включать в поставку по-умолчанию надо то, что наиболее востребовано, а после пыхов наиболее востребованы как раз рубин и питон.
> а после пыхов наиболее востребованы как раз рубин и питон.у которых есть собственные серверы, которые и используются более-менее серьёзными проектами. соответственно, я лично вообще не понимаю необходимости пришпандоривать их модулями к апачу.
а если для мелкоскриптов — так Lua и меньше, и шустрее. а если LuaJIT привинтить, то и несравнимо шустрее.
>у которых есть собственные серверы, которые и используются более-менее серьёзными проектамиВ целом вы правы, и да, действительно, под любой более-менее значимый интернет-проект минимум арендуется VPS, а куда чаще выделенный сервер с фермой ВМ под управлением какого-нибудь гипервизора. Но, к сожалению, это не перекрывает всех потребностей, потому что такая практика касается в основном именно что интернет-проектов.
С внутренними продуктами компаний дела обстоят иначе, и к моему сожалению, объективная реальность такова, что чаще всего сервера в этих компаниях работают под управлением винды. Блин, я бы рад если бы они были на лине, но решаю-то не я. Решает заказчик, а он вовсе не горит желанием менять ось на сервере из-за моего веб-проекта, каким бы он значимым не был. Вот и приходится что-то думать мне. На винде же, как всем известно, компилятор по-умолчанию отсутствует, и в этих условиях необходимость пересобирать веб-сервер под железо и ось заказчика вызывает страшенный батхерт.
Скажу за себя: лично мне проще написать костыль на питоне (что давно уже сделано), что бы ту же джангу заставить выдавать результаты через свой собственный веб-сервер для разработчиков, чем разворачивать бодяжку с компиляцией апача под платформу win32 на лине. По принципу: "Нагрузки ведь нет? Нет. Ну так значит и костыль подойдет".
Не, если припирает, то конечно - компилю. Но каждый раз матерюсь сквозь зубы, потому что понимаю что всего-то и нужно было, что включить этот ср@№ый мод в дефолтовую поставку. Но близок локоток, а не укусишь.
ну, это печальная история про винды и костыли, сказка совсем из других стран.и под «своими серверами» я подразумевал что-то типа mongrel (да, я знаю, что устарел; пардон, не в курсе, что там сейчас на замену). то есть, *веб*-сервера на том же языке, что и фрэймворк. по какому поводу необходимость в апаче — вместе с его модулями — в таких проектах стремится к нулю.
>и под «своими серверами» я подразумевал что-то типа mongrelНу что-там на рубине я не знаю (я вообще о рубине мало чего знаю), а за питон скажу: мне вот проще всего на нодах приложений ставить gunicorn в качестве встраиваемого сервера. Впрочем, если у вас более одного нода приложения, то все равно вам понадобится обратное проксирование и балансировка нагрузки, и какой-нибудь сервер на эту роль. Это не говоря уже об обслуживании статики. Я использую nginx, - мне он больше по душе. Так что и надобности в апаче не испытываю.
>по какому поводу необходимость в апаче — вместе с его модулями — в таких проектах стремится к нулюПеречитал сейчас ваши посты и понял наконец о чем вы писали. Отвечу так: вообще-то не должно бы стремиться. Потому что:
- балансировку нагрузки, обратное проксирование и обработку статики никто не отменял, и какой-то сервер для этого все равно нужен. Так почему бы и не апач?
- интерфейс wsgi в целом куда более мощное решение чем связка django+flup+fcgi и более гибкое нежели связка django+gunicorn+http, и было бы желательно использовать именно его, а из всех веб-серверов общего назначения только апач и поддерживает wsgiТак что теоретически все должно быть у апача ОК.... Но на практике, - в моем случае, например, - майнтейнеры апача сами себе ставят подножку: сделать апач частью своего единого решения я не могу из-за ограничений винды и отсутствия мода по дефолту в апаче, а за-ради одного линукса - не вижу практического смысла с апачем возится вообще - nginx объективно быстрее работает.
> - балансировку нагрузки, обратное проксирование и обработку статики никто не отменял, и
> какой-то сервер для этого все равно нужен. Так почему бы и
> не апач?потому что жирная дура.
> — интерфейс wsgi в целом
…уныл и бесполезен, потому что гвидобейсикозаточен.
>> - балансировку нагрузки, обратное проксирование и обработку статики никто не отменял, и
>> какой-то сервер для этого все равно нужен. Так почему бы и
>> не апач?
>потому что жирная дура.И однако у этой дуры есть в комплекте балансировщик http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html чуточку поумнее чем у публичного nginx, что делает ее не совсем бесполезной для нагруженных площадок. И если у вас нет в кармане своего решения для балансировки и вы не счастливый обладатель платного nginx'а (в котором вроде как это тоже имеется), то это будет как бы единственный выбор.
>> — интерфейс wsgi в целом
>…уныл и бесполезен, потому что гвидобейсикозаточен.А как же поддержка в Ruby On Rails интерфейса WSGI посредством RACK? Может не стоило горячится с такими заявлениями? И потом... я вот не знаю другого интерфейса, готового к шлюзованию приложений. Так что уныл он или нет - а здоровья придумать что-то лучшее как бы ни у кого и не нашлось, ИМХО
> И однако у этой дуры есть в комплекте балансировщик http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html
> чуточку поумнее чем у публичного nginx, что делает ее не совсем
> бесполезной для нагруженных площадок.я их не сравнивал, мнения не имею. а вот нагрузка и ресурсожорка у опача таки побольше.
при необходимости доточить ngnix-овый под свои нужды совсем несложно.
>>> — интерфейс wsgi в целом
>>…уныл и бесполезен, потому что гвидобейсикозаточен.
> А как же поддержка в Ruby On Rails интерфейса WSGI посредством RACK?не знаю, я не рубист. а быстрый гуглёж ничего особо интересного не показал.
> я вот не знаю другого интерфейса, готового к шлюзованию приложений.
фигня в том, что уныл сам гвидобейсик. да и необходимость «приложений» сильно переоценена. это как с DE: для комфортной работы вполне достаточно какого-нибудь windowmaker/fluxbox/fwvm/i3/etc, но ставят кеды. они, естественно, жрут ресурсы как не в себя, и ВНИЗАПНА! выясняется, что надо и видео помощней, и винт побыстрей, и иксы им не по нраву… ну дык побольше, побольше надстроек — одну над другой. а то техника чересчур шустрая стала, зараза.
>> Пускай его вон любители луа юзают - луашный мод
>> в поставке по-умолчанию идет.
> это явно лучше гвидобейсика будет.Ну, разве что если "скорость - это не главное... и потребление памяти тоже". Тогда да, луа лучше пистона. Вот, например, простенький бенч http://raid6.com.au/~onlyjob/posts/arena/ который показывает, что тормознее Lua - только жаба.
apt-get install libapache2-mod-wsgi
А не слабо представить что в мире есть что-то еще помимо бубунты с ее "apt-get install <руки русалки>"?
> А не слабо представить что в мире есть что-то еще помимо бубунты
> с ее «apt-get install <руки русалки>»?угу. дебиан, например. там тоже apt-get. чудо!
И даже у альтов к их странному пепелацу apt-get есть. Ну а что еще из нормальных менеджеров пакетов бывает? Yum - гадостная наколенная рапидчина, радующая тормозами. Остальные обычно сильно обрублены по возможностям.
Очевидно, yum вы видели только один раз и на картинке (плакат "они мешают нам жить"), а про остальные пакетные менеджеры вообще не слышали.
> А не слабо представить что в мире есть что-то еще помимо бyбунты
> с ее "apt-get install <руки русалки>"?Для убунтят - действительно сложно.
> wsgi так и нет в поставке по-умолчанию?Бедные бидонисты с своими кривыми недопротоколами, надизайнеными как и все остальное у бидонистов, т.е. "рапидно и безбашенно".
> Бедные бидонисты с своими кривыми недопротоколами, надизайнеными как и все остальное у
> бидонистов, т.е. "рапидно и безбашенно".Не забудьте также пожалеть рубистов с их passenger и жабистов с их tomcat. А кто еще у нас в вебе остается? Недосягаемо крутые похпешники?
Apache был и будет пока, nginx не панацея от всего, просто модно им стало пользоваться со смыслом и без.
> им стало пользоваться со смыслом и без.Так он ресурсов меньше жрет при прочих равныз и не такой монстр в целом.
> Так он ресурсов меньше жрет при прочих равныз и не такой монстр в целом.Ничего, для nginx тоже модули активно пилят. Когда будет ему лет столько же, сколько и опачу - неизбежно превратится в такого же толстого монстра.
Да, а про apt-get прикольно ...
> Да, а про apt-get прикольно ...Было бы смешно, если бы не было так грустно.