Доступен (http://www.apache.org/dist/httpd/Announcement2.4.html) релиз http-сервера Apache 2.4.9 (http://httpd.apache.org), в котором представлено 35 изменений (http://www.apache.org/dist/httpd/CHANGES_2.4.9). Выпуск 2.4.8 был пропущен из-за исправления в последний момент проблемы в mod_ssl, проявляющейся в виде краха при выполнении вызова SSL_get_certificate в случае использования некоторых устаревших версий OpenSSL, а также исправления ошибки в mod_lua, приводящей к некорректной обработке LuaMapHandler при определённом стечении обстоятельств.
По сравнению с выпуском 2.4.7 в новой версии устранено две уявзимости:- CVE-2014-0098 - возможность инициирования краха mod_log_config при попытке сохранения в лог урезанных Cookie, в которых указано только имя и пропущено значение (теперь в лог сохраняются только пары cookie=value).
- CVE-2013-6438 - возможность вызова отказа в обслуживании при обработке модулем mod_dav специально оформленных запросов "DAV WRITE" из-за неверного расчёта размера данных в условиях обрезания лидирующих пробелов.Наиболее заметные улучшения:
- В директивы LocationMatch, DirectoryMatch, FilesMatch и ProxyMatch добавлена поддержка именованных групп и обратных ссылок (backreference) в регулярных выражениях (для работы требуется сборка со свежей версией PCRE);
- В mod_rewrite в директиве RewriteOptions появилась поддержка опций InheritDown, InheritDownBefore и IgnoreInherit для организации передачи правил RewriteRules из родительской области в дочернюю без явной настройки каждой дочерней области. Добавлена поддержка переменной %{CONN_REMOTE_ADDR}, вариант %{REMOTE_ADDR} с адресом инициатора соединения;- В mod_dir добавлена директива DirectoryCheckHandler для обеспечения пропуска выполнения обработчика в случае если он уже был установлен. Отключен поиск DirectoryIndex и DirectorySlash для URL, уже переписанных в mod_rewrite;
- В mod_proxy добавлена поддержка использования unix domain sockets в качестве точки для взаимодействия с бэкендом. Прекращена поддержка недокументированного синтаксиса "Proxy ~ wildcard-url" который эквивалентен "ProxyMatch wildcard-url";
- В поддержку HTTP/1.1 внесены связанные с обработкой конфликтов TE/CL исправления, рекомендованные в документе draft-ietf-httpbis-p1-messaging-23 (https://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-23);
- В mod_ssl отключено выполнение сравнения параметров SNI и заголовка Host в случае запроса к прокси. Для директив SSLCertificateFile и SSLCertificateKeyFile прекращена зависимость от жестко заданных в коде типов алгоритмов. Объявлена устаревшей поддержка директивы SSLCertificateChainFile. Добавлена директива SSLOpenSSLConfCmd для использования команд конфигурации OpenSSL;
- Устранена проблема с длительной задержкой при использовании модели prefork и выполнения перезапуска в режиме graceful;
- Для всех версий старше FreeBSD 5 отключен по умолчанию маппинг в IPv4 для ожидающих соединение сокетов (ранее указанная поддержка была отключена только для FreeBSD 5);- В mod_remoteip обеспечено корректное заполнение поля proxy_ips;
- В mod_lua добавлена возможность возврата результатов запроса из БД в форме хэша (row-name/value) вместо массива (row-number/value), обновлена реализация r:setcookie(),
- Если невозможно декодировать сессию, то mod_session теперь всегда ведёт себя как в случае если сессии вообще нет. Устранены проблемы при интерпретации директив SessionInclude и SessionExclude;
- В mod_proxy_fcgi в качестве таймаута задейсвовано значение apr_socket_timeout_get вместо жестко определённого таймаута в 30 секунд;
- Для модулей mod_authz_user, mod_authz_host, mod_authz_groupfile, mod_authz_dbm, mod_authz_dbd и mod_authnz_ldap добавлена поддержка парсера выражений для содержимого директив.URL: http://www.apache.org/dist/httpd/Announcement2.4.html
Новость: http://www.opennet.me/opennews/art.shtml?num=39327
а истекать памятью он меньше будет?
Вы опять на ночь читали "1000 и 1 дедлайн" и "Сказки народов интернета"?
Утечки в апаче это ещё более нелепый миф, нежели утечки в огнелисе.
Миф про огнелис хотя бы базируется на устаревшей, но всё-таки правдивой информации, а утечки апача это чистой воды дезинформация от адептов nginx и прочих новомодных конкурентов:)
> а утечки апача это чистой воды дезинформация от адептов nginx и прочих новомодных
> конкурентов:)Или просто баги модулей и скриптов, etc. А также дурная модель обработки запросов "префорк" сватаемая по умолчанию.
> скриптовэто уже не баги апача =)
> это уже не баги апача =)Втюхивание по дефолту префорка для *nix-like - на их совести. Может и не баг, но фичой тоже сложно назвать. Поэтому лобовая замена апача на нжинкс дает очень положительный эффект с минимальным эффектом. Особенно на виртуалказх, vdsках и всякой околоэмбедовке.
> Втюхивание по дефолту префорка для *nix-like - на их совести. Может и не баг, но фичой
> тоже сложно назвать. Поэтому лобовая замена апача на нжинкс дает очень положительный
> эффект с минимальным эффектом. Особенно на виртуалказх, vdsках и всякой околоэмбедовке.Задачи разные бывают. Для php+статика apache-prefork, конечно, тяжеловат. Да и apache-worker тут не особо поможет.
Вот для задач в которых активно юзается проц и большое количество памяти, prefork - самое оно.
Nginx тут не катит, бо клиенты будут блокироваться на проце. Соответственно нужно большое количество воркеров, а это уже ничем не отличается от apache-prefork.
apache-worker тоже не айс, бо выигрыш по памяти будет минимальным, но если поток издохнет, то он потянет за собой остальные потоки в процессе, а там могут быть клиенты.Когда я писал модулек под apache исходил из следующих соображений:
1. Самому писать HTTP-сервер было влом
2. У апача есть DSO (привет nginx-у)
3. У апача есть apr (для lighthttpd/uwsgi надо будет все заново реализовывать, либо тянуть apr)
4. apache-prefork самое то для жрущих проц приложений
5. apache-prefork дебажить проще (дебажить nginx gdb-ой сомнительное удовольствие)
> Задачи разные бывают. Для php+статика apache-prefork, конечно, тяжеловат.А вы знаете, найти сервер где не требовалась бы статика - это еще суметь надо. А конфигурить 2 типа сервантов вместо 1 - удовольствие весьма так себе.
> Да и apache-worker тут не особо поможет.
Да они признались что апач в этом плане гэ, выпустив traffic server.
> Вот для задач в которых активно юзается проц и большое количество памяти,
> prefork - самое оно.Да, вы верно заметили: префорком жрется дофига памяти. И проц неплохо пригружается, если побольше нафоркать. И особенно если ничего не кешировать. В результате как-то так и получается что школьник с мобилкой может положить нехилый сервак, если там апач. Ну так, в среднем по больнице, в состоянии по дефолту. Наобум взятый сферический апач в вакууме кладется играючи, хоть тем же ab2 из своего же комплекта, что особенно иронично. При этом атакующему не требуется ни жирного канала, ни мощного компа :). Что позволяет кулхаксорам иметь море лулзов, а там где это ведет к потере бабла - почему-то очень быстро отрастает нжинкс который еще и кеширует в статику все что можно, а тяжелые запросы вообще дают дергать только зареганым, которых в случае чего отстрелить можно и на автомате плодить сложно. И чего это они? :)
> Nginx тут не катит, бо клиенты будут блокироваться на проце.
В каком именно месте нжинкс заблокируется? Не допираю.
> Соответственно нужно большое количество воркеров,
> а это уже ничем не отличается от apache-prefork.Обычно в случае нжинкса число воркеров равно числу процов. И воркер обслуживает кучу клиентов. Не блокируясь, ясень пень. Или вы предлагаете в сам нжинкс вгрузить логику вебни и клинить воркера пока там немеряная куча хлама усиленно вкалывает? А это зачем? К нжинксу обычно цепляют вебаппу по какому-нибудь fastcgi и оно там уже пашет. А нжинкс может например прокешировать это добрецо. Скажем если у нас вика и ее никто не редактировал - на кой буй ее 100 раз в секунду генерить заново, выжирая все процы в полку и напрягая движок БД? Можно же из кеша отдать страницу и никто не заметит разницы. Кроме сервера, который будет дергать навороченные скрипты не 100 раз в секунду а, например, раз в пять минут (пять секунд, полчаса, неделю...).
> apache-worker тоже не айс, бо выигрыш по памяти будет минимальным, но если
> поток издохнет, то он потянет за собой остальные потоки в процессе,
> а там могут быть клиенты.Может. Если идея в том чтобы вкорячить логику прямо туда.
> Когда я писал модулек под apache исходил из следующих соображений:
А не проще писать аппу на фастцги? Либы для этого есть, etc, так что рассказы про то как самому тяжко выписывать протоколы - булшит какой-то.
>>но если поток издохнет, то он потянет за собой остальные потоки в процессе, а там могут быть клиенты.наверное с нгинксом будет все то же самое, если зафигачить в него модулем какой-нибудь язык?
и почему должен дохнуть поток, например, если использовать тот же самый mod_proxy_fcgi?
>замена апача на нжинкс дает очень положительный эффект с минимальным эффектомкратко и по существу. :)
> а истекать памятью он меньше будет?Звучит как "истекать кровью"
> а истекать памятью он меньше будет?Меньше, чем nginx, да.
использую, где нужен .htaccess. Правда фронтом nginx ставлю с попытками статику выдавать именно фронтом.
А что в нём есть нужного, кроме .htaccess? Статику лучше nginx отдавать. PHP, Perl, Python совместно с nginx без проблем работают.
Да собсно особенно ничего. Иногда только бывает проще поставить апач, если с быдлокодером работаешь, который агрессивно относится к подкручиваению всяких read_timeout, etc....
Лучше не работать с быдлoкодерами, имхо.
+1, но
no users, no troubles, no money =)
> no users, no troubles, no money =)Кому как, кому как.
То есть у тебя user and troubles but no money?
Это успех чо ...
> То есть у тебя user and troubles but no money?Какой вы неоптимистичный. К счастью, не у всех все так плохо как у вас :).
У нас то как раз всё хорошо.
Захочет клиент опача оплатить - получит опача ...
У нас вообще практически любой каприз за ваши деньги :)А у вас? :) 100500 vds на одном писюге?
> А у вас? :) 100500 vds на одном писюге?А мы работаем себе в удовольствие и не занимаемся низкопробной дрянью. Вот такие мы нехорошие.
Надо отдать должное разработчикам Apache они не смотря ни на что трудятся над улучшением этого замечательного продукта. ПО надо выбирать исходя из задач а не из за фанатических убеждений.
> Надо отдать должное разработчикам Apache они не смотря ни на что трудятся
> над улучшением этого замечательного продукта. ПО надо выбирать исходя из задач
> а не из за фанатических убеждений.Продукт нормальный, есть много чего из коробки, вполне себе юзабельно. Я лично в большистве случаев ушел на другие сервера, но я же - это не все. У многих он работает и вполне себе даже.
Где HTTP/2.0 draft ?
> Где HTTP/2.0 draft ?Рано, поскольку его еще даже в браузеры не во все запихнули, это тот самый случай когда развитие начинается с конца )))
Ну а если серьезно может его в новой ветке пилят, апачи ко всем технологиях и нововведениям относятся ну очень осторожно. У них на все свой собственный инкубационный период и им все равно происходит у других
Честно признаюсь я в Апаче не сильно разбираюсь, с полгода назад или чуть раньше я его себе поставил для самообразования, потом поднял https, потом сделал принудительный ридерект с http на https.
Все было хорошо...пока я не обновился где-то неделю назад, после этого после перезагрузки Апач перестал работать, systemd говорил что не может загрузить модули, указанные в конфиге, по причине их отсутствия, какие-то опции вообще упразднились, вообщем комментить строки в конфиге на 500 строк и перезапускать Апач как-то не очень хотелось. С новыми конфигами, что шли в комплекте все было чики, НО - чтобы заработал тот же PHP пришлось снова указывать на загрузку модуля для php, еще какие-то строки добавлять в конфиг. Писец - это что в порядке вещей так у Апача ? а обратная совместимость ? даже при помощи diff -a хрен проссышь что указывал в конфиге год назад для своей системы.
Нет правда - обязательно было делать так, что если упразднили опцию
SSLRequire
в файле
/etc/httpd/conf/extra/httpd-vhosts.conf
то обязательно нужно делать, чтобы Апач не стартовал ? нельзя было ворнингом в лог-файл ограничиться ?
Просто апатч это конструктор лего из некрофильнутых конфигов
В вашем случае возможны проблемы, но они скорее относятся в конкретному дистрибутиву нежели непосредственно к Apache. Более того ошибки возможны из за вашей неопытности, так что следует почитать документацию или почитать замечания маинтейнера бинарного пакета того дистрибутива которым вы пользуетесь. В общем гугление вам в помощь
> перезагрузки Апач перестал работать, systemd говорил что не может загрузить модули,
> указанные в конфиге, по причине их отсутствия, какие-то опции вообще упразднились,
> вообщем комментить строки в конфиге на 500 строк и перезапускать Апач
> как-то не очень хотелось.Знаешь, подобный шитец на самом деле и с другим случается. Уж у нжинкса переделать конфиг не совсем совместимо с старой версией - вообще чуть ли не в порядке вещей.
Возможна-ли хоть одна новость про вебсерверы без срача про nginx? Задрали, поцреоты.