Comment contrôler NGINX "Localisation" de la directive ordre de pertinence?

J'essaie d'optimiser mon "localisation" des directives et ne peut pas trouver un bon moyen de déterminer si un emplacement spécifique de match est même tentée. À l'aide de echo à l'intérieur de l'emplacement du bloc n'aide pas ici.

La NGINX ngx_http_core_module documentation est quelque peu déroutant.

D'utiliser des expressions régulières, vous devez utiliser un préfixe:

  1. ~ Pour la casse correspondant

  2. ~* Pour la correspondance insensible à la casse

Comment le match est effectuée:

  1. Directives avec la = préfixe correspondant à la requête exactement. Si elle est trouvée, la recherche s'arrête.

  2. Toutes les autres directives classiques cordes. Si ce match a utilisé le ^~ préfixe, la recherche s'arrête.

  3. Expressions régulières, dans l'ordre qu'ils sont définis dans le fichier de configuration.

  4. Si #3 a abouti à un match, ce résultat n'est utilisé. Sinon, le match de #2 est utilisé.

Numéro 2 ici dit "classique chaînes" mais alors, dit-il peut être utilisé avec le ^~ préfixe. Ne pas ~ implique une RegExp? Si non, comment est-il déterminer ce qu'est une n'est pas une RegExp?

Plus précisément, je veux la suite:

  1. Servir à rien de littéral /assets directement. ARRÊTER LA RECHERCHE.

  2. Servir quelque chose correspondant RegExp \.php$|/$ via fast-CGI ARRÊTER la RECHERCHE.

  3. Servir tout le reste directement via littérale /

De cette façon, il ya seulement un / match tentative pour non-dynamique des fichiers desservies à partir de l'extérieur de l'actif.

J'ai:

location ^~ /assets {}      # search-terminating literal? or regex?
location ~ \.php$|/$ {}
location /{}               # is this match always attempted?

À partir du document, il semble que la commande serait 1-3-2, toujours en cours d'exécution littérale / match. Oui, cette optimisation ne fera aucune différence pour la performance réelle, mais je veux juste clarifier certaines ambiguïtés.

InformationsquelleAutor leeoniya | 2011-12-08
  1. 7

    À partir du wiki:

    location  = /{
  # matches the query /only.
  [ configuration A ] 
}
location  /{
  # matches any query, since all queries begin with /, but regular
  # expressions and any longer conventional blocks will be
  # matched first.
  [ configuration B ] 
}

    Donc, ce sera assortie d'abord:
    location ~ \.php$ {}

    Même si des biens sont servis à partir de location /{}

    À l'intérieur du bloc php vous aussi vous voulez de les protéger contre les téléchargements malveillants avant de passer à fastcgi:

    if ($uri ~* "^/uploads/") {
  return 404;
}

    Comme vous pouvez le voir nginx fonctionne un peu différemment que vous pourriez vous attendre.

    • je ne suis toujours pas à comprendre pourquoi les regex serait payée en premier. accordée il y a pas de "=" directives. la prochaine étape est le "Toutes les autres directives classiques de chaînes". '/' est un classique de la chaîne et devraient être adaptés avant tout regex. l'ensemble des chaînes-puis-regex est une main-tenant implicite d'optimisation de nginx semble faire ici, ce qui rend impossible difficile de déterminer le vrai ordre d'évaluation. je pense apache/iptables etc réussir prévisible de traitement dans le même ordre défini comme un if/else-if/else bloc. sans aucune implicite "plus/moins" règles spécifiques.
    • À droite, c'est certainement un peu confus au sujet de nginx, en particulier nginx est if qui doit être utilisé uniquement pour réécrire/retour. Je pense qu'ils sont de travail sur la simplification de la ce. Pour votre situation, il fonctionne comme ceci: 1. php regex pour vérifier avec un arrêt si c'est un match de 2. / pour tout le contenu statique.
    • vous vous êtes trompé sur la commande. l'intérêt de la /des actifs de la règle comme une chaîne de caractères première est d'éviter la surcharge de l'exécution de la regex php à chaque requête. en fait, je VEUX servir de quelque chose comme assets/docs/example.php sans passer par FCGI. je suis en train d'exécuter ce programme d'installation et la regex n'a PAS de prise pour example.php. il est ordonné que ^~ /actifs, /, ~ \.php$|/$
    • Vous pouvez poser quelque part sur nginx pour voir si cela peut être fait exactement comme ça. Aussi regarder try_files. En utilisant nginx sur Apache est un gain de performances bien 🙂
    • Vraiment bien que je pense que vous avez tort de s'inquiéter à propos de ce gain de performance. Combien de traitement supplémentaire il va ajouter à chaque statique de la demande? Comparez cela avec php délais de traitement et les temps de transfert d'actifs qui sont servis dans des fichiers distincts (au lieu de concaténés en un seul). Je parie que je pourrais trouver de nombreux endroits dans votre demande que vous devriez vous inquiéter.
    • ouais je sais, comme je l'ai indiqué dans l'OP, ce n'est pas vraiment sur la performance mais sur la clarté dans la compréhension des règles de correspondance. leur nature implicite/complexité les rend plus difficiles à maintenir, et sujettes à erreur, donc moins sécurisé

    InformationsquelleAutor m33lky