Como o try_files funciona?

Question

Eu olhei para a documentação do nginx e isso ainda me confunde completamente.

Como o try_files funciona? Aqui está o que a documentação diz:

De NginxHttpCoreModule

try_files

syntax: try_files path1 [path2] uri

default: none

context: server, location

availability: 0.7.27

Checks for the existence of files in order, and returns the first file that is found. A trailing slash indicates a directory - $uri /. In the event that no file is found, an internal redirect to the last parameter is invoked. The last parameter is the fallback URI and must exist, or else an internal error will be raised. Unlike rewrite, $args are not automatically preserved if the fallback is not a named location. If you need args preserved, you must do so explicitly:

Eu não entendo como ele verifica os caminhos e se eu não quiser um erro interno, mas ele deve retomar o resto do caminho em um esforço para encontrar outro arquivo?

Se eu quiser testar um arquivo em cache em /path/app/cache/url/index.html e se ele não tentar usar /path/app/index.php , como eu escreveria isso? Se eu escrevi:

try_files /path/app/cache/ $uri
include /etc/nginx/fastcgi_params;
fastcgi_pass unix:/var/run/php-fastcgi/php-fastcgi.socket;
fastcgi_param SCRIPT_FILENAME $document_root/index.php;

Eu tenho index index.php index.html index.htm; . Quando visito /urlname , ele tentará verificar /path/app/cache/urlname/index.php e /path/app/cache/urlname/index.html ? Se ignorarmos tudo depois de try_files , é possível que try_files verifique a pasta de cache? Eu tenho tentado e falhei.

    

Answer 1

try_files tenta o caminho literal especificado em relação à diretiva raiz definida e define o ponteiro do arquivo interno. Se você usar por exemplo try_files /app/cache/ $uri @fallback; com index index.php index.html; , ele testará os caminhos nesta ordem:

1. $document_root/app/cache/index.php
2. $document_root/app/cache/index.html
3. $document_root$uri

antes de finalmente redirecionar internamente para o local denominado @fallback. Você também pode usar um arquivo ou um código de status ( =404 ) como seu último parâmetro, mas se estiver usando um arquivo, deve existir .

Você deve notar que o próprio try_files não emitirá um redirecionamento interno para nada além do último parâmetro. Isso significa que você não pode fazer o seguinte: try_files $uri /cache.php @fallback; , pois isso fará com que o nginx defina o ponteiro de arquivo interno como $ document_root / cache.php e o sirva, mas como não há redirecionamento interno, os locais não são reavaliados e, como tal, será servido como texto simples. (O motivo pelo qual ele trabalha com arquivos PHP como o índice é que a diretiva de índice irá emitir um redirecionamento interno)

    

Answer 2

Aqui está outro uso conveniente de try_files, como redirecionamentos incondicionais para locais nomeados. Os locais nomeados estão efetivamente atuando como sub-rotinas, economizando duplicação de código. Quando o primeiro argumento para try_files é "_", o redirecionamento de fallback é sempre usado.

    location =/wp-login.php { try_files _ @adminlock; }
    location ^~ /wp-admin/  { try_files _ @adminlock; }
    location @adminlock  {
            allow 544.23.310.198;
            deny all;
            try_files _ @backend;
            # wp-admin traffic is tiny so ok to send all reqs to backend 
    }
    location ~ \.php {  try_files _ @backend; }
    location / { try_files $uri $uri/ =403; }
    location @backend {
            fastcgi_pass 127.0.0.1:9000;
            include snippets/fastcgi-php.conf;
    }