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

[Dmitry Koterov]

...й пример. :-)

> Возможные решения проблемы тут уже не раз обсуждались, наиболее
> привлекательным выглядит использование именованных captures.
Если я правильно понял, эти решения еще не реализованы в nginx, они только
обсуждались? Ведь именованные captures вроде пока не поддерживаются... Если
все-таки решение есть, пришлите ссылку, пожалуйста, потому как поиском
находится только ветка http://www.lexa.ru/nginx-ru/msg22571.html (про то,
что нужно вместо rewrite использовать regex location, т.к. последний не
меняет captures в случае несовпадения).


2009/11/9 Dmitry Koterov <dmitry at koterov.ru>

> Спасибо за подробны
>
> 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/c7838f40/attachment.html>