Comments 6
на оффтопике, apache, проделывал 15 лет назад
IndexOptions XHTML ...
получится xml-совместиный выхлоп и добавив туда <?xml-stylesheet href="...
по схеме "xslt-over-xhtml" раскрашивать листинги как душе угодно.
трансформация выполняется на клиенте в браузере, до сих пор все поддерживают,
а кто не сумел в xslt просто получит не такой красивый вариант...
я в общем-то так и не понял - в чём недостаток fancyindex?
спрашиваю не холивара ради, я его использую и каких-то недостатков замечено не было, да и шкурку для него лет так за 5 не появилось желания менять..
В общем-то основные минусы в статье упомянуты.
Любой сторонний модуль на Си в nginx и любом его форке - это потенциальная головная боль, мина замедленного действия. Никаких гарантий совместимости API даже между минорными версиями у nginx нет. В любой момент, после очередного обновления, модуль может начать подтекать, либо вызывать ещё какие-то проблемы, совершенно неожиданные. И обычно первое же, что мы просим при жалобе на любой баг - это попробовать воспроизвести без сторонних модулей, ибо статистика по ним печальная.
Поэтому если можно лишний раз не использовать какой-то сторонний модуль, то лучше и не использовать.
К тому же в официальных репозиториях nginx, например, никакого fancyindex модуля нет. Т.е. если вы его используете, то видимо собирали самостоятельно, либо nginx у вас установлен не из официального репозитория. Качество пакета nginx в сторонних репозиториях, в том числе репозиториях дистрибутивов, оставляет желать лучшего. Там обычно пакетами занимаются плохо разбирающиеся в нюансах nginx мейнтейнеры. Как результат, сборщики в Debian умудрялись долгое время собирать пакет с серьезной уязвимостью - очень наглядный прецедент. Да и версии пакетов зачастую в других репозиториях отстают, из-за чего серьезные и важные исправления порой сильно запаздывают.
Никаких гарантий совместимости API даже между минорными версиями у nginx нет
А у Angie есть ?
Нет. Это архитектурная проблема nginx, которую невозможно исправить не сломав обратную совместимость тотально. Там нет как такового публичного обособленного интерфейса для разработчиков модулей, а просто выставлены внутренние кишки наружу, как есть, и способ сборки с ними.
В итоге понятие API для модулей размыто: практически всё является публичным API и даже то, во что авторы не предполагали, что модулям следует лезть. Поэтому любая доработка или исправление бага потенциально может что-то сломать в чужом коде.
Это с одной стороны дает мощь и гибкость: в модулях можно реализовать практически что угодно, а с другой создает множество проблем в плане поддержки всего этого хозяйства.
nginx пытался решать это с помощью njs, агитируя писать расширения в рамках встроенного движка JavaScript.
Мы в Angie ещё добавили возможность делать это на WASM: https://angie.software/angie/docs/configuration/modules/wasm/
Использовать xslt для красивенького индекса - конечно можно, но это из пушки по воробьям. xslt-модуль умеет делать совершенно фантастические вещи, а не только такую мелкую ерунду.
Стильный современный «autoindex» в Angie/nginx без sms и сторонних модулей