Comment résoudre le piège de la configuration nginx add_header

Avant-propos

add_header est une commande définie dans le module headers. Comme son nom l'indique, elle est utilisée pour ajouter des en-têtes de réponse http. Mais veuillez noter qu'il s'agit simplement d'un "ajout", pas d'une réécriture. Donc, si un en-tête existe déjà, l'utilisation de add_header posera des problèmes. De plus, dans les versions inférieures de nginx, add_header ne prend pas en charge l'utilisation dans les pages d'erreur.

C'est une instruction comportant de nombreux écueils. Son étape de traitement est ultérieure au traitement de l'emplacement. Bien qu'il puisse être écrit dans l'emplacement, si un autre emplacement est réécrit, l'add_header non traité dans l'emplacement précédent sera perdu. Par exemple :

location = /a {
 add_header a 1;
 rewrite / /b;
}
location = /b {
 add_header b 2;
 return 204;
}

n’a pas d’en-tête 1, n’est-ce pas ? C'est un gouffre !

Un autre piège est le problème répétitif mentionné au début. Par exemple, je souhaite définir le type de contenu pour un élément de contenu, mais comme il existe un default_type défini globalement, il est répété.

default_type 'text/plain';

location = /a {
 add_header content-type application/json;
 return 200 '"ok"';
}

Bien sûr, il existe de nombreuses solutions, comme laisser le default_type vide pour cet emplacement, ou simplement ne pas utiliser add_header et modifier directement le default_type pour cet emplacement.

Le dernier gros écueil est qu'il ne peut pas prendre effet sur les pages d'erreur, ce qui est d'ailleurs clairement défini dans. Par exemple, l'exemple suivant :

location = /a {
 add_header content-type application/json;
 return 404 '"not found"';
}

J'espère répondre avec un json, mais comme le code d'état est 404, l'add_header ici ne prendra pas effet.

Bien que cet exemple puisse utiliser default_type pour résoudre le problème, que se passe-t-il s'il s'agit d'autres en-têtes ? Par exemple, que dois-je faire avec access-control-allow-origin ? Ensuite, il n'y a pas de solution sauf utiliser Lua ou d'autres modules tiers pour le résoudre. Bien entendu, nginx est également conscient de ce problème, le document indique donc également qu'il prend en charge un paramètre appelé toujours après la version 1.7.5. Bien que nginx ait résolu ce problème par lui-même, Tengine basé sur 1.6.2 est sur le point d'échouer.

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!