Re: index internal redirect

[Gena Makhomed <gmm@xxxxxxxxx>]

On 16.06.2011 23:16, Валентин Бартенев wrote:

> > Для try_files хотелось бы придумать ещё два модификатора - делать
> > внутренний редирект при нахождении файла (как сейчас делается для index)
> > и проверка абсолютного пути (а не относительно root/alias).
> > Например, абсолютный путь - два начальных слэша:
> >
> >     try_files  //path/to/maintenance.html  $uri  $uri/  @php;
> try_files  !$uri  @php;
>
> где ! - инвертирует результат обнаружение файла.
не совсем понятно, как этот синтаксис должен работать.
что делать в том случае, если файла действительно нет?
и что надо делать в том случае, когда такой файл есть?

> Или такая запись:
>
> try_files  $uri@php $uri/  =404;
>
> т. е. @name, приставленная вплотную к конкретному пути, говорит нам о том, что
> если этот путь найден то обрабатываем его в @name
вместо такого sendmail-подобного расширения синтаксиса:

try_files  $uri@php $uri/  =404;

предлагаю лучше читаемый и лучше расширяемый вариант синтаксиса:

try_files  internal_redirect( @php )::$uri
           $uri/
           =404
           ;

> Извините, что несколько не по теме, но для alias хотелось бы иметь возможность
> писать так:
>
> location ~* ^/[a-z0-9\.]+\.(pgp|gpg|key)$ {
>      alias /www/http/_global/key.pgp;
> }
>
> т. е. location с регуляркой и без выделений, а alias на конкретный файл.
разве это сейчас нельзя сделать, - если в location создать выделение,
которое всегда будет равно пустой строке и добавить его в строку alias?

проверил на тестовом сервере с nginx 1.0.0:

    location ~* (.?)^/[a-z0-9\.]+\.(pgp|gpg|key)$ {
        alias $1/etc/nginx/site/q/global_key.pgp;
    }

это работает как и ожидалось, и $1 вcегда равно пустой строке.

в то же время, текущее поведение nginx:

Если директива alias используется внутри location'а, заданного 
регулярным выражением, то регулярное выражение должно содержать 
выделения, а директива alias ? ссылки на эти выделения
вполне полезно и разумно, потому что помогает защититься
от случайных опечаток и ошибок при конфигурировании nginx.

лучше ничего не менять и не убирать это ограничение, тем более,
что оно очень легко обходится, если это действительно кому-то надо.

P.S. разве что имеет смысл добавить в документацию nginx
описание метода преднамеренного обхода этого ограничения.

--
Best regards,
 Gena


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