index internal redirect

[Gena Makhomed]

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 at php $uri/  =404;
>
> т. е. @name, приставленная вплотную к конкретному пути, говорит нам о том, что
> если этот путь найден то обрабатываем его в @name

вместо такого sendmail-подобного расширения синтаксиса:

try_files  $uri at 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