Apache 1.3.36

Вчера же появился и mod_ssl 2.8.27 для apache 1.3.36

Все здоровые люди уже давно пользуються 2.2 а они все это страрье обновляют

Ну а что делать нездоровым?

Ждать ебилдов ;)

Скорее очень не здоровые. На продакшене у вменяемых 1.3, в крайнем случае 2.0.x.

Например: http://netstat.ru/?do=static&p=httpd&class=4

Вы им верите?

Согласно http://netstat.ru/?do=static&p=os&class=3 больше 40 процентов windowsов - это ME.

Основная доля - серверы мелких компаний с не самым крутым железом и 3-5 клиентами. Дальнейшие вопросы будут?

Я скорее верю не им, а своим глазам и знакомым :). Провы у нас в большинстве сидят на 1.3.

+1 Согласен..

>Все здоровые люди уже давно пользуються 2.2 а они все это страрье >обновляют.

Для тебя здоровые люди это красноглазые дебилы ???

netstat.ru уже очень давно показывает откровенную ахинею. Сравните например его рейтинги с рейтингами РуЦентра (http://stat.nic.ru/2006/05/19/server_zone-20060519.shtml) или с http://domstat.p8.ru. У netstat'а даже близко правдой не пахнет.

Теперь Слака впереди планеты всей?

http://slackware.com/security/viewer.php?l=slackware-security&y=2006&...

>Все здоровые люди уже давно пользуються 2.2 а они все это страрье обновляют

Скажите, зачем нужен 2.X, если вполне устраивает 1.3.X? Подавляющему большинству пользователей НЕ нужен Apache2.

>На продакшене у вменяемых 1.3

а он epoll/kqueue разве могет?

Я даже не знаю может или не может.

У меня эта ветка работает 4й год и ничего менять в обозримом будущем я не собираюсь.

Нафиг что-то менять если оно работает?

>а он epoll/kqueue разве могет?

Для тех задач в которых используется *любой* Apache, ни epoll ни kqueue попросту не нужен. Потому как максимум времени занимает не сетевое взаимодействие, а обработка самого запроса.

А для действительно высоконагруженных сервисов существуют более другие HTTP сервера, например, nginx, 0w-httpd, thttpd.

Переходить же на Apache 2.X только ради того, что у него выше номер версии - глупо.

Re>"Скажите, зачем нужен 2.X, если вполне устраивает 1.3.X?"
ну, хотя бы для того, чтобы не юзать костыли вроде russian apache..
или у Вас всё сайты в одной кодировке?
а так - сказал AddDefaultCharset - <кодировка> и всё ок.

Ну может и не 2.2 но нормальные люди должны пользоваться 2.0.

Кстати, почему вы, например, не пользуетесь апачем 1.0 а 1.3, а? Давайте пользоваться более старым старём чем ваш 1.3

У меня в koi8 и 1251

в .htaccess говоришь AddDefaultCharset и все работает на 1.3

ЗЫ - а кто такой русский апач? :)

Re>"ЗЫ - а кто такой русский апач?"
cat /usr/ports/russian/apache13/pkg-descr
Russian Apache is an HTTP server designed to work on a Russian market.
All the documentation is on-line on the WWW homepage.
WWW: http://apache.lexa.ru/

"Этот сервер посвящен программе Russian Apache - HTTP-серверу на основе Apache к которому добавлена поддержка нескольких кодировок текста."(c) http://apache.lexa.ru

неужели я перепил пива и apache1.3 умеет отдавать клиенту информацию о том, в какой кодировке отдавать документ?

2sergej
oops, по ходу и впрямь, уже умеет.. :
http://httpd.apache.org/docs/1.3/mod/core.html#adddefaultcharset

ничего не понимаю..(с) когда мы в последний раз спорили с уважаемыми мною админами о том, что ставить на машину под хостинг - их главным аргументом было как раз "AddDefaultCharset directive"

впрочем это было почти год назад. быть может тогда он этого ещё не умел.

>а так - сказал AddDefaultCharset - <кодировка> и всё ок.

Это работает и в нерусском Apache 1.3.XX

>Кстати, почему вы, например, не пользуетесь апачем 1.0 а 1.3, а? Давайте пользоваться более старым старём чем ваш 1.3

Объясняю: потому, что функционала версии 1.3.X ВПОЛНЕ хватает для решения всех текущих задач.

Большинство фичей Apache 2.X реально не нужно для подавляющего количества пользователей.

Если текущая версия устраивает, и при этом она поддерживается разработчиком, смысла перехода с нее нет.

При этом производительность и Apache 1.3 и Apache 2.X достаточно невелика для того, чтобы гнаться именно за *скоростью*, повторяю, для этого есть более другие HTTP сервера.

И именно потому использовать 1.0 - 1.2 нет смысла -- они не поддреживаются разработчиком. А 1.3 - поддерживается, следовательно, у всех вменяемых хостеров и просто адекватных админов она будет стоять до те пор, пока не перестанет поддерживаться Apache.org.

>Кстати, почему вы, например, не пользуетесь апачем 1.0 а 1.3, а? Давайте пользоваться более старым старём чем ваш 1.3

>Объясняю: потому, что функционала версии 1.3.X ВПОЛНЕ хватает для решения всех текущих задач.

>Большинство фичей Apache 2.X реально не нужно для подавляющего количества пользователей.

>Если текущая версия устраивает, и при этом она поддерживается разработчиком, смысла перехода с нее нет.

>При этом производительность и Apache 1.3 и Apache 2.X достаточно невелика для того, чтобы гнаться именно за *скоростью*, повторяю, для этого есть более другие HTTP сервера.

>И именно потому использовать 1.0 - 1.2 нет смысла -- они не поддреживаются разработчиком. А 1.3 - поддерживается, следовательно, у всех вменяемых хостеров и просто адекватных админов она будет стоять до те пор, пока не перестанет поддерживаться Apache.org.

Ясно. Создаем петицию к апач.орг, чтобы он перкратил поддержку 1.3 :)

Хм, а я вообще отказался от апача много лет назад, и ни разу не возникло
необходимости в его возврате. Везде стоит mathopd. Всё то же самое,
только 1) выше производительность 2) намного меньшее потребление памяти
3) нативный suexec без костылей 4) намного выше устойчивость - он
никогда не ложился без спросу ;)

>Хм, а я вообще отказался от апача много лет назад, и ни разу не возникло необходимости в его возврате.

И как у этого mathopd обстоят дела с загружаемыми модулями a-la Apache? А как дела с документированным API, чтобы писать свои модули-расширения?

Да там весь код - пара сотен строчек. А какие модули нужны веб-серверу?
Его дело контент отдавать быстро и надёжно.

>Да там весь код - пара сотен строчек. А какие модули нужны веб-серверу?

СОбственные самописные модули, очевидно. Тот же SVN DAV.

>Его дело контент отдавать быстро и надёжно.

И больше ничего не уметь? Если так, то сравнивать этот сервер с Apache нельзя -- это мягко говоря, продукты из разных ниш.

Мне нужно, чтобы в html, который отдаётся cgi-скриптом, работали ssi-директивы. Как мне это сделать на apache 1.3?

>Мне нужно, чтобы в html, который отдаётся cgi-скриптом, работали ssi-директивы. Как мне это сделать на apache 1.3?

Мда.... CGI да еще и с SSI... Это необходимо, наверное, для того, чтобы сделать сервер не слишком быстрым, да?

Использование SSI после CGI - это признак того, что вебмастеру надо срочно менять род своей деятельности. Например, пойти работать дворником.

Есть вещи, которые попросту не надо хотеть делать. И то, что Apache 1.3 не позволяет SSI в выводе CGI/mod_perl/mod_php - это хорошо. Точно также, как хорошо, что в ядре Linux не зашит X-Сервер.

> СОбственные самописные модули, очевидно. Тот же SVN DAV.

Я не понимаю смысла в таких решениях. Теоретически модулем к вебсерверу
можно сделать любое приложение, к примеру форум, блог и т.д. Только
какой эффект этим достигается? Почему доступ к CVS через веб сделан
как cgi-приложение, а SVN DAV обязательно должен быть модулем apache?
Какие препятсвия есть в создании обычного cgi-приложения для этих
целей?

>Мда.... CGI да еще и с SSI... Это необходимо, наверное, для того, чтобы сделать сервер не слишком быстрым, да?

Это нужно для того, чтобы результат работы cgi-скриптов отдавался в дизайне сайта. Хедер, футер и проч. общие блоки, которые лежат отдельными кусками. Самый простой пример - результат голосования. Более сложный - интерфейс работы с персональными данными (анкета, личные сообщения и т.д.).

>Это нужно для того, чтобы результат работы cgi-скриптов отдавался в >дизайне сайта. Хедер, футер и проч. общие блоки, которые лежат >отдельными кусками. Самый простой пример - результат голосования. Более >сложный - интерфейс работы с персональными данными (анкета, личные >сообщения и т.д.).


Открой для себя XML+XSLT и после этого ты перестанешь писать не снимая штанов.

>Я не понимаю смысла в таких решениях. Теоретически модулем к >вебсерверу можно сделать любое приложение, к примеру форум, блог и >т.д. Только какой эффект этим достигается?

Скорость, очевидно. Если контент нельзя кешировать (например, вебмагазин или поисковая система), а посещаемость высокая, никакой CGI не справится.

>а SVN DAV обязательно должен быть модулем apache?

Почитайте спецификацию на DAV, вопросы моментально отпадут.

>Это нужно для того, чтобы результат работы cgi-скриптов отдавался в > дизайне сайта. Хедер, футер и проч. общие блоки, которые лежат >отдельными кусками. Самый простой пример - результат голосования. >Более сложный - интерфейс работы с персональными данными (анкета, >личные сообщения и т.д.).

Откройте для себя технологии отделения данных от их представления

http://reki.ru/products/ctpp perldoc HTML::Template http://smary.php.net XML + XSLT и так далее

> Почитайте спецификацию на DAV, вопросы моментально отпадут.

Посмотрите на http://pear.php.net/package/HTTP_WebDAV_Server/
и ответьте на мой первоначальный вопрос - почему он должен быть модулем.

> XML + XSLT и так далее

А вот это дерьмо не надо советовать, если вы не вникли ещё в убогость
такого решения.

>А вот это дерьмо не надо советовать, если вы не вникли ещё в убогость такого решения.

Ну конечно же! CGI + SSI -- это совсем-совсем не убогая технология.

epoll умеет squid пропатченный работающий в качестве фронтенда :-) про kqueue не знаю, надо у фряшников уточнять :) Ну и наверняка nginx тоже умеет.