...й пример. :-)<br><br>> Возможные решения проблемы тут уже не раз обсуждались, наиболее<br>
> привлекательным выглядит использование именованных captures.<br>
Если я правильно понял, эти решения еще не реализованы в nginx, они только обсуждались? Ведь именованные captures вроде пока не поддерживаются... Если все-таки решение есть, пришлите ссылку, пожалуйста, потому как поиском находится только ветка <a href="http://www.lexa.ru/nginx-ru/msg22571.html">http://www.lexa.ru/nginx-ru/msg22571.html</a> (про то, что нужно вместо rewrite использовать regex location, т.к. последний не меняет captures в случае несовпадения).<br>
<br><br><div class="gmail_quote">2009/11/9 Dmitry Koterov <span dir="ltr"><<a href="mailto:dmitry@koterov.ru">dmitry@koterov.ru</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Спасибо за подробны<br><br><div class="gmail_quote">2009/11/7 Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span><div><div></div><div class="h5"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello!<br>
<div><br>
On Sat, Nov 07, 2009 at 01:05:31AM +0300, Dmitry Koterov wrote:<br>
<br>
> > Все переменные (и $1 не исключение) подставляются в тот момент,<br>
> > когда строка содержащая переменные реально используется.<br>
> ><br>
> ИМХО для $1, $2 и т.д. такое поведение как раз не очень логично... но,<br>
> наверное, по-другому сделать архитектурно сложнее.<br>
<br>
</div>Вообще использование $1 в разных директивах декларативного конфига<br>
- это выстрел в ногу.<br>
<div><br>
> > > Я ожидал, что в конструкции<br>
> > ><br>
> > > set $docroot /your/app/$1/htdocs;<br>
> > ><br>
> > > в $docroot попадет уже ОКОНЧАТЕЛЬНАЯ строка, в которой нет упоминаний $1<br>
> > и<br>
> > > т.д... Аналогично, что в<br>
> ><br>
> > Да, попадёт. Когда отработает соответствующий set. Это случится<br>
> > где-то в районе фазы серверных rewrite'ов (если set на уровне<br>
> > server{}).<br>
> ><br>
> > Шутка состоит в том, что эта самая фаза - выполняется повторно при<br>
> > очередном поиске совпадения между uri и location (после rewrite ...<br>
<br>
</div>Я ошибся, после rewrite ... last серверные рерайты снова не<br>
отрабатывают. Только после внутренних редиректов (e.g. по<br>
X-Accel-Redirect, index, error_page, ...).<br>
<div><br>
> > last). И там снова отрабатывает set. И заново ставит $docroot,<br>
> > но на этот раз в $1 уже может быть совсем не то что ожидалось.<br>
> ><br>
> Спасибо, примерно понятно.<br>
> Можно ли (для истории) попросить Вас привести пример конфига, иллюстрирующий<br>
> этот эффект?<br>
<br>
</div>Конфиг:<br>
<br>
server {<br>
server_name ~^www\.(.*)\.example\.com$;<br>
listen 8081;<br>
<br>
set $name $1;<br>
root /tmp/$name;<br>
<br>
location / {<br>
rewrite ^blah blah break;<br>
index index.html;<br>
}<br>
}<br>
<br>
Есть файл:<br>
<br>
/tmp/xxx/index.html<br>
<br>
Запрашиваем <a href="http://www.xxx.example.com/index.html" target="_blank">www.xxx.example.com/index.html</a> - получаем файл,<br>
запрашиваем <a href="http://www.xxx.example.com/" target="_blank">www.xxx.example.com/</a> - получаем внутренний редирект на<br>
/index.html и тыкву (404) на выходе, потому что не имеющий<br>
отношения к делу rewrite поменял captures.<br>
<br>
Возможные решения проблемы тут уже не раз обсуждались, наиболее<br>
привлекательным выглядит использование именованных captures.<br>
<font color="#888888"><br>
Maxim Dounin<br>
<br>
</font></blockquote></div></div></div><br>
</blockquote></div><br>