рерайт, авторизация, манипулирование параметрами для отдельных папок, листинг директорий, да уйма всякого, дайте это все в нгинксе и тогда я откажусь от апача.
и переписывать все готовые рерайты для сайтов под nginx, вписывать их в конфиг, так как нельзя использовать хтакцесс для этих целей, спасибо конечно, но эти модули не панацея
это важно коль вы предлагаете использовать ваш код как шаблон, до 0.8 версии в nginx были доступны относительные пути, то есть фактически можно считать любой файл.
Если же запущен под правами пользователя то ему нужен доступ ко всем home директориям, при этом пользователи потеряют возможность пользоваться ключиками.
В предпоследней строке: «Естественно, что остальную конфигурацию придумываем самостоятельно — это лишь шаблон на заметку»,- т.е. подразумевается, что это вовсе не вся секция server и отнюдь не все location. ;)
На текущий момент nginx СУЩЕСТВЕННО превосходит лайти, который к тому же уже не развивается. Там как чуть дальше стандартного набора копнёшь — плеваться хочется. Может в 2.0 исправят дело но когда это будет?
Как это не развивается? У него всегда были редкие релизы, редко чаще раз в три месяца, вы посмотрите коммиты в репозитории, прежде чем говорить. Куда вы копнули что вам захотелось плеваться? О каком 2.0 речь, если следующая версия — 1.5?
Тут уж не холиваром попахивает, а откровенной попыткой полить гавном то, о чем ничего не знаете. Не вводите людей в заблуждение-то.
товарищ глубоко в танке?
1.4 только баги правят, 1.5 RIP как полгода, а 2.0 даже тарболы всё ещё не собирают!
Копали мы очень хорошо и в разные стороны.
К примеру:
лайти в принципе однотредовый/однопроцессовый — если возникает блокирующая операция (а они возникают на IO при использовании glusterfs) то виснет ВЕСЬ вебсервер. У энджа есть воркеры…
лайти позволяеть перехватывать лишь избранные HTTP ошибки, что просто «пи-пи-пи» при 413-ой
как network-backend нормально работает только writev, остальные — экспериментальные. И это удалось выяснить только после переписки с разработчиками.
отсутствие средств управления ресурсами из коробки — даже mod_speed.c надо отдельно компилить
настройка SSL ужасный костыль
и так далее и тому подобное
А nginx всегда наводил на меня уныние и ужас своими конфигами.
Для сравнения — redmine.lighttpd.net/projects/lighttpd/wiki/Docs:ModUserDir настройка в 3 строчки в лайти и целый огород костылей в nginx.
Пример в чём выражается существенное превосходство в студию.
в энджинксе логика конфига просто несколько иная.
если бы ни в общем-то бесполезный модуль mod_userdir то делали бы точно также как в энджинксе регексом по url
считаешь модуль нужным? напиши его под nginx! никто до сих пор не написал? значит не нужный!
>а разницы между lighttpd и nginx в скоростях похоже нет или не очень заметна
У меня на Q9400 lighttpd (20000 запросов, 50 потоков) отдаёт 14,5 тыс простых статических запросов в секунду, а nginx — 6,5 тыс.
Самое смешное, что если lighttpd сидит бэкендом за nginx (у меня сложилась временно такая дурацкая схема), то получается 8,5 тыс. От числа потоков соотношение меняется мало.
Какой Вы не догадливый. lighttpd — прямой аналог nginx'а. И в нём можно попробовать реализовать функционал, нужный топикстартеру. Соответственно, комментарий об этом.
А вот вместо производительного web-сервера Ваш BMW Z4 не поставить. Так что Ваш комментарий — действительно, не в тему.
Но есть mod_magnet, который для каждого файла позволяет выполнять высокопроизводительный (скорость фактически как у статики) скрипт на lua. Соответственно, этим конфигом можно прочесть данные из каталога, где лежит отдаваемый файл (и пробежаться вверх по уровням), найти пользовательский конфиг-файл и отпарсить его, получив такой же, как .htaccess функционал.
Если не полениться, то можно, наверное, и точный парсер .htaccess написать. Всё же, полноценный язык программирования используется.
HTACCESS не нужен для серверов ориентированных на обслуживание 10 тысяч клиентов одновременно.
Ибо использование HTACCESS подразумевает поиск файла .htaccess во всём дереве пути к запрашиваемому файлу что требует дискового IO который замедляет обработку запросов.
nginx — настройка фронтенда к ~username — public_html