Потому что там есть аналогичная функциональность, но с другим синтаксисом. Можно написать модуль, но правильнее будет переписать правила, которые учитывают специфику движка.
А, и правильно что нет. Но из плюса вырастает и минус: а если мы хотим дать пользователю тоже править эти правила? Он пишет в поддержку, те высылают текущие настройки (если высылают), правит, высылает им, они применяют, потом пользователь проверяет, видит, что всё сломалось, пишет новый вариант,... И каждый раз надо делать nginx reload, что не всегда удобно. А если 2 клиента прислали конфиги, и 1 с ошибкой.. если оно в свн, делать откат обоих? В общем, оно не для масс хостинга как минимум. Да и банально - накосячили, хотим откатить, копии нет. Лишний .htaccess можно тупо стереть, а тут?
да, это в случае "как_по_умолчанию_все_сайты_в_1_конфиге" Я сразу с первых часов создал папку sites и в главном в http прописал include "sites/*.conf", где каждый server в своем файле.
Потому что там есть аналогичная функциональность, но с другим синтаксисом. Можно написать модуль, но правильнее будет переписать правила, которые учитывают специфику движка.
ReplyDeleteНу да это понятно, тут вопрос стоял "почему у нгинкса нету раскиданных по тыщще папок конфигов".
ReplyDeleteА, и правильно что нет. Но из плюса вырастает и минус: а если мы хотим дать пользователю тоже править эти правила? Он пишет в поддержку, те высылают текущие настройки (если высылают), правит, высылает им, они применяют, потом пользователь проверяет, видит, что всё сломалось, пишет новый вариант,...
ReplyDeleteИ каждый раз надо делать nginx reload, что не всегда удобно. А если 2 клиента прислали конфиги, и 1 с ошибкой.. если оно в свн, делать откат обоих? В общем, оно не для масс хостинга как минимум.
Да и банально - накосячили, хотим откатить, копии нет. Лишний .htaccess можно тупо стереть, а тут?
да, это в случае "как_по_умолчанию_все_сайты_в_1_конфиге"
ReplyDeleteЯ сразу с первых часов создал папку sites и в главном в http прописал include "sites/*.conf", где каждый server в своем файле.