http {
include mime.types;
default_type application/octet-stream;
server {
root /websites;
listen 80;
server_name localhost;
# ne fonctionne pas
try_files /logo.png /logo.jpg /error;
# fonctionne
rewrite ^/e /error;
# fonctionne
# return 200 "$request_uri Géré par le bloc serveur";
location / {
default_type text/plain;
return 200 "Préfixe racine correspondant";
}
location /error {
default_type text/plain;
return 404 "Logo non trouvé";
}
}Je veux savoir quelle est la cause de cette évaluation, je n'ai trouvé aucune explication fiable ni dans la documentation ni sur les forums.
En passant, j'ai expérimenté le scénario suivant:
- Suppression du bloc location / {} et cela a fonctionné comme prévu. Je sais que lorsque la demande est faite au serveur, elle est d'abord évaluée par le bloc serveur et ensuite correspond aux blocs location. Mais il semble que la directive
try_filessoit ignorée (POURQUOI?!!). Si je comprends bien, le dernier argument de la directivetry_filesréécrit l'URI donc il devrait se comporter comme la directive rewrite. Les directives rewrite et return ont fonctionné comme prévu, elles ont été évaluées à chaque fois indépendamment de l'existence de blocs location correspondants ou non.
J'ai beaucoup recherché pour trouver des informations fiables expliquant cette situation, mais je n'ai pas réussi. Donc je demande ici la réponse ou la source sur les informations internes de Nginx à quelqu'un qui sait.
0 votes
Votre hypothèse selon laquelle "elle est d'abord évaluée par le bloc serveur" n'est pas correcte.
0 votes
@RichardSmith. Merci pour votre attention. Pouvez-vous s'il vous plaît expliquer pourquoi?
1 votes
@SafarSafarli En plus de ce qui a déjà été dit par Richard Smith, vous devez savoir qu'il existe différentes phases de traitement des demandes. Consultez la documentation de développement de nginx ou cet article pour plus d'informations. Les directives du module de réécriture
ngx_http_rewrite_moduleplacées au niveau du serveur sont traitées pendant laNGX_HTTP_SERVER_REWRITE_PHASEtandis que la directivetry_filesest traitée pendant laNGX_HTTP_PRECONTENT_PHASE.0 votes
@IvanShatsky, Merci pour votre attention.
0 votes
@IvanShatsky J'ai lu la section de l'article que vous avez fournie. Mais j'ai trouvé un peu difficile à comprendre, par exemple : "
ngx_http_try_files_moduleetngx_http_mirror_moduleenregistrent leurs gestionnaires à cette phase..". Appelerngx_http_try_files_moduleun module est déroutant, ne devrait-on pas plutôt utiliser le mot "directive"?0 votes
@SafarSafarli La directive
try_filesréside en fait dans son proprengx_http_try_files_moduleplutôt que dansngx_http_core_module(voir les liens GitHub fournis vers le code source de nginx).0 votes
@IvanShatsky, alors, pourquoi est-il placé comme une directive du module de base ? nginx.org/en/docs/http/ngx_http_core_module.html. C'est tellement déroutant
0 votes
@SafarSafarli J'ai trouvé une réponse à votre question. Il s'agissait de la directive du module de base jusqu'à une refonte qui a eu lieu en 2017. Jusqu'à ce que la directive `try_files` utilise une phase spéciale `TRY_FILES_PHASE` qui était disponible exclusivement pour `try_files` et aucune autre directive. Avec la refonte, une nouvelle phase `PRECONTENT_PHASE` a été ajoutée au flux de traitement des requêtes de nginx et la mise en œuvre de la directive `try_files` a été déplacée vers un module séparé utilisant cette phase. Désormais, n'importe quel module tiers peut utiliser cette nouvelle phase `PRECONTENT_PHASE` ainsi que le module `nginx_http_try_files_module`.
0 votes
@SafarSafarli Donc, je pense que l'équipe nginx a simplement décidé de ne pas réécrire la documentation. Il y a une petite différence du point de vue de l'utilisateur final. De toute façon, vous ne pouvez pas désactiver ni
nginx_http_core_moduleninginx_http_try_files_modulelorsque vous compilez nginx à partir des sources. Vous pouvez consulter le commit de refonte susmentionné du code source de nginx ici.