Comment si les conditions de travail à l'intérieur de l'emplacement du bloc de conf nginx?

J'ai lu
https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/

Je veux vérifier si mon application rails a déjà ajouté un en-tête (Access-Control-Allow-Origin) et si elle n'a pas puis ajouter l'en-tête.

Les exemples ici ont tenté d'expliquer le comportement de if condition de nginx.conf http://agentzh.blogspot.in/2011/03/how-nginx-location-if-works.html

Mais je n'ai pas compris. L'une des questions que je me pose est ce que l'on entend lorsque l'on dit d'une directive ou d'une phase de la directive?

J'ai essayé quelques choses moi-même. Comme:

location /{
  add_header My-outer-header '*';
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header Host $http_host;
  proxy_set_header X-NginX-Proxy true; 

  if($sent_http_access_control_allow_origin != /*){
    add_header My-inner-header '**';
  }
}

Ici lorsque les si la condition est remplie, seulement My-inner-header est de définir et de ne pas le My-outer-header.

Mais quand je fais:

location /{
  add_header My-outer-header '*';
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header Host $http_host;
  proxy_set_header X-NginX-Proxy true; 
  set $a 1;
  if($a == 1){
    add_header My-inner-header '**';
  }
}

Ici $une variable est définie sur 1, mais seulement la My-inner-header est nouveau et pas le My-outer-header.

Je veux vérifier et de s'assurer si les instructions comme proxy_set_header sont arriver exécuté ou non.

OriginalL'auteur Abhishek Kumar | 2016-02-07

nginx nginx-location

4

Je n'ai pas testé votre code. Je ne parle par expérience!!!

Pour commencer, permettez-moi de préciser que Nginx configuration n'est PAS du tout semblable à tout OOP comportement (Programmation Orientée Objet). Il est en un seul mot imprévisible "Déclaratif".

Sens... Si vous avez 2 SI les déclarations dans le même bloc que les deux répondent aux critères, SEUL le deuxième prévaudra et sera exécutée.

La même chose arrive avec 1 si et tous ses déclarations précédentes dans le même bloc. Certaines variables (Pas tous) ne pourra pas être exécutée en raison de la présence de SI, et nginx attend d'eux d'être re-déclarée à l'intérieur.
Ce qui se passe dans votre exemple. Prenons le second pour plus de clarté.
À l'intérieur de votre emplacement bloc, vous déclarez plusieurs valeurs d'en-tête. MAIS, lorsque l'instruction if est rencontré, ils ne sont PAS exécutées (SI le mal de nginx en effet). Afin d'avoir une pleine exécution vous avez besoin de re-déclarer la plupart de vos variables en-tête à l'intérieur et à rien d'autre en dehors du si, encore une fois à l'intérieur de l'instruction if, de sorte qu'ils seront exécutés dans le cas où l'instruction if est rencontré. REMARQUE, il n'y a pas de carte qui répertorie toutes les variables affectées par SI dans nginx et de tester notre conf pour les éventuelles erreurs. Certaines variables n'ont PAS besoin d'être déclarée et dans ce cas nginx affiche un message d'erreur au redémarrage. Seul moyen de savoir laquelle, c'est d'aller pour tous et de la règle de l'rapporté erronée.

Suggestions

a) a Éviter SI dans nginx, si possible. Utilisation de l'emplacement des blocs de la place.
par exemple, Si vous souhaitez simplement ajouter un en-tête variable comme Access-Control-Allow-Origin pour certains fichiers, ne PAS utiliser si, mais au lieu d'un deuxième emplacement de bloc (Voir ci-dessous)
```
location /{
  //some code here
}
location ~* \.(eot|ttf|woff|woff2)$ {
    add_header Access-Control-Allow-Origin *;
}
```
b) Dans le cas où SI est obligatoire, à utiliser avec prudence et test test test. Comme ci-dessus, re-déclarer tout dans l'instruction if est une bonne pratique (Comme suggéré ci-dessus, le test et la règle de tout re-déclaration des sauts de configuration).

Bonne chance.

OriginalL'auteur Angelos Hadjiphilippou

Vous devez vous connecter pour publier un commentaire.