Analyse d'un exemple d'instruction Nginx add_header

Avant-propos

Comme nous le savons tous, le fichier de configuration nginx définit l'en-tête de réponse en utilisant la directive add_header.

En utilisant curl pour vérifier les informations d'un site, j'ai constaté que l'en-tête renvoyé est différent de ce à quoi je m'attendais :

http/2 200
date: thu, 07 feb 2019 04:26:38 gmt
content-type: text/html; charset=utf-8
vary: accept-encoding, cookie
cache-control: max-age=3, must-revalidate
last-modified: thu, 07 feb 2019 03:54:54 gmt
x-cache: miss
server: cloudflare
...

Le site principal a configuré des en-têtes tels que hsts dans nginx.conf :

add_header strict-transport-security "max-age=63072000; preload";
add_header x-frame-options sameorigin;
add_header x-content-type-options nosniff;
add_header x-xss-protection "1; mode=block";

Mais l'en-tête de réponse le fait Je n'ai pas ces en-têtes. En plus des en-têtes habituels, il n’y a qu’un seul x-cache d’en-tête configuré à l’emplacement.

La première impression est que CDN filtre ces en-têtes ? J'ai donc cherché la documentation de cloudflare, mais je n'ai pas trouvé qu'elle pouvait les gérer. Ensuite, j'y ai réfléchi, que fait CDN pour les filtrer ? Êtes-vous rassasié après avoir mangé ? Ils ne font pas de censure !

Le problème se déplace vers la configuration de nginx. Ouvrez Google et recherchez "nginx location add_header", et vous trouverez de nombreuses failles. Cliquez sur le document add_header sur le site officiel et il y a cette description (d'autres informations ont été omises) :

il peut y avoir plusieurs directives add_header, ces directives sont héritées du niveau précédent si et seulement si aucune directive add_header n'est définie. au niveau actuel .

L'attention est portée sur "ces directives sont héritées du niveau précédent si et seulement si aucune directive add_header n'est définie au niveau actuel.". Autrement dit : les paramètres parents ne seront hérités que s'il n'y a pas de directive add_header dans le niveau actuel. Ma question est donc claire : il y a add_header à l'emplacement et la configuration dans nginx.conf est ignorée.

Il s'agit d'un comportement intentionnel de nginx, et cela ne peut pas être considéré comme un bug ou un piège. Mais si vous comprenez bien cette phrase, vous découvrirez un phénomène plus intéressant : seul le dernier add_header fonctionne. add_header peut être configuré dans http, le serveur et l'emplacement, mais la configuration la plus proche prendra effet et toutes les configurations ci-dessus seront invalides.

Mais le problème ne s’arrête pas là. Si l'emplacement est réécrit vers un autre emplacement, seul le deuxième en-tête apparaîtra dans le résultat final. Par exemple :

location /foo1 {
 add_header foo1 1;
 rewrite / /foo2;
}

location /foo2 {
 add_header foo2 1;
 return 200 "ok";
}

Quelle que soit la requête /foo1 ou /foo2, l'en-tête final n'est que foo2 :

Bien qu'il soit logique que ce soit un comportement normal, cela semble toujours un peu forcé et inconfortable : le serveur perd le configuration http et l'emplacement est perdu La configuration du serveur est bonne, mais les deux emplacements sont au même niveau !

Vous ne pouvez pas hériter de la configuration parent et vous ne souhaitez pas répéter les instructions dans le bloc actuel. La solution peut être d'utiliser l'instruction include.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!