web-dev-qa-db-fra.com

Comment fonctionne try_files?

J'ai regardé la documentation de nginx et cela m'embrouille toujours complètement.

Comment try_files travail? Voici ce que dit la documentation:

à partir de NginxHttpCoreModule

try_files

syntaxe: try_files chemin1 [chemin2] uri

par défaut: aucun

contexte: serveur, emplacement

disponibilité: 0.7.27

Vérifie l'existence des fichiers dans l'ordre et renvoie le premier fichier trouvé. Une barre oblique de fin indique un répertoire - $ uri /. Dans le cas où aucun fichier n'est trouvé, une redirection interne vers le dernier paramètre est invoquée. Le dernier paramètre est l'URI de secours et doit exister, sinon une erreur interne sera déclenchée. Contrairement à la réécriture, $ args n'est pas automatiquement conservé si le repli n'est pas un emplacement nommé. Si vous avez besoin d'arguments conservés, vous devez le faire explicitement:

Je ne comprends pas comment il vérifie les chemins d'accès et que se passe-t-il si je ne veux pas d'erreur interne mais que je le fasse reprendre le reste du chemin d'accès afin de trouver un autre fichier?

Si je veux essayer un fichier mis en cache à /path/app/cache/url/index.html et s'il ne parvient pas à essayer /path/app/index.php comment pourrais-je écrire cela? Si j'écrivais:

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;

J'ai index index.php index.html index.htm;. Quand je visite /urlname, essaiera-t-il de vérifier /path/app/cache/urlname/index.php puis /path/app/cache/urlname/index.html? Si nous ignorons tout après try_files est-il possible pour try_files pour vérifier le dossier de cache? J'ai essayé et j'ai échoué.

nginx
77
user274

try_files essaie le chemin littéral que vous spécifiez par rapport à la directive racine définie et définit le pointeur de fichier interne. Si vous utilisez par exemple try_files /app/cache/ $uri @fallback; avec index index.php index.html; puis il testera les chemins dans cet ordre:

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

avant de finalement rediriger en interne vers l'emplacement nommé @fallback. Vous pouvez également utiliser un fichier ou un code d'état (=404) comme dernier paramètre mais si vous utilisez un fichier, il doit exister.

Vous devez noter que try_files lui-même n'émettra pas de redirection interne pour autre chose que le dernier paramètre. Cela signifie que vous ne pouvez pas effectuer les opérations suivantes: try_files $uri /cache.php @fallback; car cela amènera nginx à définir le pointeur de fichier interne sur $ document_root/cache.php et à le servir, mais comme aucune redirection interne n'a lieu, les emplacements ne sont pas réévalués et en tant que tels, ils seront servis en texte brut. (La raison pour laquelle cela fonctionne avec PHP comme index est que la directive index émettra une redirection interne))

68
Martin Fjordvald

Voici une autre utilisation pratique de try_files, en tant que redirections inconditionnelles vers des emplacements nommés. Les emplacements nommés agissent efficacement comme des sous-programmes, ce qui évite la duplication de code. Lorsque le premier argument de try_files est _ la redirection de secours est toujours prise (en supposant que _ n'est pas un nom de fichier existant). Parce que nginx a besoin d'une instruction goto mais n'en a pas.

    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;
    }
7
Craig Hicks