Hello!

On Wed, Oct 16, 2013 at 09:28:40PM +0300, Gena Makhomed wrote:

> On 16.10.2013 20:33, Maxim Dounin wrote:
>
> >>>>кстати, если добавить директиву handler, которая работает после фазы
> >>>>try_files, то можно будет писать конфиг nginx без лишней избыточности:
> >>>>
> >>>>location /admin {
> >>>> satisfy any;
> >>>> set $file ".htpasswd";
> >>>> auth_basic_user_file /path/to/$file;
> >>>> allow 10.1.1.1;
> >>>> deny all;
> >>>> handler @default;
> >>>>}
> >>
> >>>Можно добавить множество новых директив. Но, как показывает
> >>>практика, это не избавляет от старых проблем, а только добавляет
> >>>новых. Не надо умножать сущности без необходимости.
> >>
> >>а какие новые проблемы добавятся в этом случае?
> >
> >Понятия не имею - подобные вещи выясняются в основном в процессе,
> >кроме уж совсем очевидных глупостей. Я как бы пытаюсь сказать,
> >что на обсуждаемый вопрос с allow/deny vs return это добавление
> >никак не повлияет.
>
> тогда "allow/deny vs return" перестанет быть такой уж острой проблемой.
> сейчас код "error_page 456 @default; return 456;" использовать нельзя,
> потому что он отрабатывает до access-проверок и админка будет без защиты

Повторяю: не перестанет. Если есть проблема - нужно её решать, а
не придумывать альтернативы. Потому что так или иначе _будут_
люди, которые пишут return, rewrite, и т.п. неправильно. И от
добавления нового механизма - их не станет меньше. Лучшее, на что
приходится расчитывать, это что их станет меньше в процентах от
общего числа пользователей - но и это не гарантировано. Наоборот,
есть неслабая вероятность, что их станет больше, потому что
пользователи окончательно запутаются в существующих механизмах.

[...]

> >Игорь тут уже как-то попробовал решать проблемы модуля rewrite с
> >помощью добавления директивы try_files. Стало только хуже, т.к.
> >старые проблемы никуда не делись, а новых добавилось - в
> >количестве.
>
> а какие проблемы появились из-за добавления директивы try_files ?

Вот тут небольшая подборка плохого:

http://trac.nginx.org/nginx/ticket/97

И это не говоря о всяких мелочах вроде "try_files не работает
из-за if'а", которые традиционно относятся к проблемам if'а, и
развлечениях людей, которым доставляет отсутствие наследования
try_files.

> ведь изменения там были минимальными:
>
> location / {
> try_files $uri $uri/ @drupal;
> }
>
> - это просто синтаксический сахар для
>
> location / {
> error_page 404 = @drupal;
> log_not_found off;
> }

Хороший пример конфига, в котором try_files - использовать, вообще
говоря, не надо. Хотя писать и проще.

Вариант с error_page 404 - атомарен, в то время как в варианте с
try_files - race condition. Между проверкой существования файла и
его реальным открытием в модуле static для возврата клиенту - файл
может быть удалён, и клиенту вернут 404. Не говоря уже про лишний
syscall.

[...]

> вообще-то это достаточно удобно и часто надо: существующие на диске
> файлы обрабатывать одним способом, а запросы, которые не соответствуют
> существующим на диске файлам - другим способом. try_files тут помогает
> обойтись без использования if из модуля rewrite: if ( -f $uri ) {...},
> который отрабатывает до access-проверок и служит для выбора location.
>
> допустим, нет у нас директивы try_files. каким образом тогда можно
> сделать с помощью nginx защищенную basic auth и allow/deny админку,
> в которой статика будет отправляться клиентам напрямую, существующие
> на диске файлы с расширением .php будут обрабатываться другим способом,
> а запросы которым не соответствует файл на диске - третьим способом ?
>
> было бы очень интересно посмотреть на вариант решения без try_files.

Я бы делал как-то так (с точностью до проверки существования
php-файлов на диске, дополнить при необходимости):

location /admin/ {
allow ...
deny ...
auth_basic ...

error_page 404 = /admin/404;
log_not_found off;

location = /admin/404 {
...
}

location ~ \.php$ {
fastcgi_pass ...
...
}
}

Впрочем, вариантов - масса, написать allow/deny/auth_basic никто
не запрещает больше, чем в одном location'е. И совершенно не
обязательно "обходиться без использования if".

Из действительно приятных применений try_files - это проверки
многих файлов "за раз", e.g. проверки всяких кешей с разными
именами ($uri.htm, $uri.html, $uri.xml и т.п.), а равно проверки
существования файла во множестве разных мест. Писать подобные
конструкции на error_page 404 - мучительно.

Речь, впрочем, не об этом. Речь о том, что try_files, который
делался как попытка "решить" проблемы if'а, вытеснив его из
конфигов, ни разу его не вытеснил. Наоборот, к существовавшим
ранее проблемам - добавились новые, в том числе - связанные с
работой try_files со всё тем же if'ом.

--
Maxim Dounin
http://nginx.org/en/donation.html

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru