Re: Nginx, regex-домены, "root /your/app/$1/htdocs"

[Dmitry Koterov]

Спасибо за подробны

2009/11/7 Maxim Dounin <mdounin at mdounin.ru>

> Hello!
>
> On Sat, Nov 07, 2009 at 01:05:31AM +0300, Dmitry Koterov wrote:
>
> > > Все переменные (и $1 не исключение) подставляются в тот момент,
> > > когда строка содержащая переменные реально используется.
> > >
> > ИМХО для $1, $2 и т.д. такое поведение как раз не очень логично... но,
> > наверное, по-другому сделать архитектурно сложнее.
>
> Вообще использование $1 в разных директивах декларативного конфига
> - это выстрел в ногу.
>
> > > > Я ожидал, что в конструкции
> > > >
> > > > set $docroot /your/app/$1/htdocs;
> > > >
> > > > в $docroot попадет уже ОКОНЧАТЕЛЬНАЯ строка, в которой нет упоминаний
> $1
> > > и
> > > > т.д... Аналогично, что в
> > >
> > > Да, попадёт.  Когда отработает соответствующий set.  Это случится
> > > где-то в районе фазы серверных rewrite'ов (если set на уровне
> > > server{}).
> > >
> > > Шутка состоит в том, что эта самая фаза - выполняется повторно при
> > > очередном поиске совпадения между uri и location (после rewrite ...
>
> Я ошибся, после rewrite ... last серверные рерайты снова не
> отрабатывают.  Только после внутренних редиректов (e.g. по
> X-Accel-Redirect, index, error_page, ...).
>
> > > last).  И там снова отрабатывает set.  И заново ставит $docroot,
> > > но на этот раз в $1 уже может быть совсем не то что ожидалось.
> > >
> > Спасибо, примерно понятно.
> > Можно ли (для истории) попросить Вас привести пример конфига,
> иллюстрирующий
> > этот эффект?
>
> Конфиг:
>
>    server {
>        server_name ~^www\.(.*)\.example\.com$;
>        listen 8081;
>
>        set $name $1;
>        root /tmp/$name;
>
>        location / {
>            rewrite ^blah blah break;
>            index index.html;
>        }
>    }
>
> Есть файл:
>
> /tmp/xxx/index.html
>
> Запрашиваем www.xxx.example.com/index.html - получаем файл,
> запрашиваем www.xxx.example.com/ - получаем внутренний редирект на
> /index.html и тыкву (404) на выходе, потому что не имеющий
> отношения к делу rewrite поменял captures.
>
> Возможные решения проблемы тут уже не раз обсуждались, наиболее
> привлекательным выглядит использование именованных captures.
>
> Maxim Dounin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20091109/a31ca79e/attachment.html>