Apache rewrite rule => Nginx rewrite rule

if ( -f $request_filename.php) {
    rewrite ^([^/.]+)/?(.*)$ /$1.php/$2 last;
    rewrite api/([a-z]+)/([a-z]+) /api/$1_$2.php last;
}

Предполагается, что все это внутри location / {}.

Естественно.

И? Что не работает? Если можно, с конкретными примерами.

ЗЫ: у меня правила от Ваших отличаются, если что.

Например не работают ссылки типа /tags/ололо, при этом /tags работает

Тогда так:

location / {
    if ( -f $request_filename.php ) {
        rewrite ^/([^/.]+)(/.*)?$ /$1.php$2 redirect;
        rewrite ^/api/([a-z]+)/([a-z]+) /api/$1_$2.php redirect;
    }
}

теперь /tags рерайтит в /tags.php , а /tags/ололо остается неизменным

А файл tags/ололо.php существует-то?

существует только tags.php, остальное через него из базы берется

Ну тогда проблема в условии if ( -f $request_filename.php ). Оно проверяет именно существование файла.

Набор файлов из первой части условия (([^/.]+)) ограничен?

ограничен ~41-м php файлом

Можно просто сделать

location ~ /(tags|...|...) {
    rewrite ^/(tags|...|...)(/.*)?$ $1.php$2 break;
}

Извращение :-(

[code] location / { set $file ""; set $exists ""; if ( $request_filename ~ ^(/[^/.]+)(/.*)?$ ) { set $file $1; }

if ( $file = «» ) { # что-то делаем }

if ( -e $file ) { rewrite ^(/[^/.]+)(/.*)?$ /$1.php$2 last; } } [/code]

Честно скажу, что не проверял, но идея такая.

error_page 404 = @myhandler;
log_not_found off;

location @myhandler {
    fastcgi_pass ...;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
    include /etc/nginx/fastcgi_params;
    fastcgi_param SCRIPT_NAME /index.php;
}

location ~ \.php$ {
    try_files $uri @myhandler;

    fastcgi_index index.php;
    fastcgi_pass ...;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include /etc/nginx/fastcgi_params;
}

index.php анализирует $_SERVER['REQUEST_URI'] и принимает решения о пути выполнения программы. В результате имеем простую логику в конфиге и отсутствие необходимости перебирать кучу правил/проверок на существование при каждом запросе.

Понимаю, что скрипт менять, вероятно, поздно, но это рекомендуемая практика. А использование всяких if ( -f ... ) плохо в любом случае.

Щас модно через try_files делать т.к. if-ы часто приводят к глюкам и сегфолтам.

try_files в случае ТС не поможет: ему нужно выполнить переписывание урла в случае, если файл существует.

try_files $request_filename.php ...; просто бы передал управление этому файлу.

на сколько я понимаю из доков это не так, в том же локейшене можно указать и реврайт, см. пример с дрюпалом: http://sysoev.ru/nginx/docs/http/ngx_http_core_module.html#try_files

Не совсем.

Например, try_files $uri $uri/ @something; сначала ищет файл $uri, если не нашел, то каталог $uri/, если же нет и каталога, то отдаёт управление именованному location.

Т.е. в случае try_files rewrite внутри location будет выполнен, если файл/каталог $uri НЕ существует. ТС нужно наоборот: если файл существует, то выполнить rewrite.

Ты же указал правильный конфиг в Apache rewrite rule => Nginx rewrite rule (комментарий) , о чём сейчас споришь? try_files лишь позволяет перекидывать в fallback-локейшн если файла нет, а если есть try_files работает так как буд-то и нет этой директивы.

А, вот в чем дело :-) Я просто думал, что речь идет об оригинальном сообщении ТС, а не о предложенном мной конфиге.

Да, тогда можно и try_files.

Причина, по которой я предпочитаю error_page на верхнем уровне, такова: если у нас есть несколько разных location, для которых 404 ошибку должен обрабатывать один и тот же скрипт — как в Апаче

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

то try_files придется повторять во всех location, ибо он не наследуется.

То есть

try_files $uri $uri/ @wordpress;

location ^~ /wp-content/uploads/ {
    location ~ \.(css|js|gif|png|jpg|flv|swf|htm|html|zip|gz|xml|JPG|bz2|txt|ico|avi|mpe?g|mp[34])$ {
        expires 30d;
        try_files $uri $uri/ @wordpress;
    }

    location ~ \.php$ {
        types {
            text/plain php;
        }
    }
}

location @wordpress {
    fastcgi_pass unix:/dev/shm/php-fcgi.sock;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
    include /etc/nginx/fastcgi_params;
    fastcgi_param SCRIPT_NAME /index.php;
}

location ~ \.php$ {
    try_files $uri @wordpress;
    fastcgi_index index.php;
    fastcgi_pass unix:/dev/shm/php-fcgi.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include /etc/nginx/fastcgi_params;
}

Без этого nginx прочто будет возвращать свою дефолтную 404 страницу.

А так проще (особенно, если много location):

error_page 404 = @wordpress;
log_not_found off;

try_files $uri $uri/ @wordpress;

location ^~ /wp-content/uploads/ {
    location ~ \.(css|js|gif|png|jpg|flv|swf|htm|html|zip|gz|xml|JPG|bz2|txt|ico|avi|mpe?g|mp[34])$ {
        expires 30d;
        try_files $uri $uri/ @wordpress;
    }

    location ~ \.php$ {
        types {
            text/plain php;
        }
    }
}

location @wordpress {
    fastcgi_pass unix:/dev/shm/php-fcgi.sock;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
    include /etc/nginx/fastcgi_params;
    fastcgi_param SCRIPT_NAME /index.php;
}

location ~ \.php$ {
    try_files $uri @wordpress;
    fastcgi_index index.php;
    fastcgi_pass unix:/dev/shm/php-fcgi.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include /etc/nginx/fastcgi_params;
}

Так как error_page наследуется, то конфиг получается короче.

Во последнем конфиге try_files $uri $uri/ @wordpress; после expires 30d; лишний. Невнимательно скопипастил :-(

Интересный подход, спасибо за разъяснения.