Re: rewrite в именованный location

[Gena Makhomed <gmm@xxxxxxxxx>]

On 14.10.2011 13:53, Igor Sysoev wrote:

> > не планируется ли сделать в nginx синтаксический сахар
> > для конструкции "error_page 345 = @name; return 345;" ?
> >
> > потому что хак "try_files @name;" короткий, но не красивый.
> > идеальным вариантом синтаксиса наверное будет "goto @name;" ?
> >
> > и/или "rewrite ^ @name;" если бывает необходимо сделать условный goto,
> > который будет выполняться только если $uri соответствует regexp`у.
> >
> > наверное в 80-90% всех случаев надо будет только безусловный goto,
> > а "условный goto" будет нужен не так часто, поэтому лучше оба варианта?
> >
> > P.S. http://catap.ru/blog/2009/07/28/nginx-rewrite-to-named-location/
> Лично я против goto, потому что это приведёт к тому, что люди ради
> экономии пары строк будут его использовать там, где нужно сделать
> законченную конфигурацию внутри location'а. Это а) приводит
> к неподдерживаемым конфигурациям, b) такие конфигурации будут
> присылаться в список и мне придётся им разбирать. Не хочу.
Ok, но ведь с другой стороны http://wiki.nginx.org/IfIsEvil
и полностью безопасной конструкцией внутри if(){ } является
только return или rewrite с уходом в другой location.

Поэтому конструкция "error_page 345 = @name; return 345;"
применяется в качестве workaround`а, чтобы можно было сделать
в конфиге то, что никакими другими способами сделать нельзя.

Против goto и Дейкстра, http://ru.wikipedia.org/wiki/GOTO
по аналогичным причинам. А как насчет вариата "rewrite ^ @name;"?
- это ведь rewrite, и то что по сути есть goto - не так очевидно.

Просто "rewrite ^ @name;" - это гораздо меньше текста писать надо,
и кроме того, не надо будет придумывать уникальные цифровые метки,
как это делается в goto через "error_page 345 = @name; return 345;"

==================================================================

Хорошим вариантом для устранения избыточности конфига могли бы быть
макросы, аналогичные апачевскому mod_macro, только в C-like синтаксисе.
по сути, макросы - это include с параметрами, но без отдельного файла.

Читаемость конфига и легкость поддержки от этого только вырастут, имхо.
Например, с аналогичными целями в исходниках nginx применяется #define,
чтобы не нарушать http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Выносить "общие" фрагменты конфига в отдельные внешние файлы -
это очень неудобно при большом количестве виртуальных хостов.
И нельзя сразу понять, где еще используется включаемый файл,
так что не очевидно, что изменится после его редактирования.

Или лучше всего - сделать свой собственный генератор конфига nginx,
так что на входе у него будет как угодно компактный и удобный DSL,
а на выходе - raw конфиг nginx, с большой избыточностью текста.
Но это ведь дополнительный уровень, который может добавлять ошибки.

Каких-либо других способов уменьшить избыточность конфига nginx,
и нарушение принципа DRY кроме трех вышеперечисленных - не нахожу.
Возможно - больше никаких способов кроме этих трех и не существует.

Стратегически - какое направление будет самое правильное и лучшее?
Учитывая, что число пользователей будет расти и не все читали доку,
- наверное аналог апачевского mod_macro, чтобы убрать избыточность?

--
Best regards,
 Gena

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