Je rencontre un problème étrange avec Nginx. Voici une configuration minimale qui reproduit l'erreur :
server {
server_name mydomain.com;
listen 111.111.111.111:80;
root /some/path;
set $some_var $sent_http_content_type;
add_header "X-Debug" $sent_http_content_type;
}
Dans ce cas X-Debug
n'est jamais affiché dans la réponse. Mais, si je commente cette ligne :
set $some_var $sent_http_content_type;
tout fonctionne. Cela me semble très étrange, car cette ligne ne réaffecte pas le fichier $sent_http_content_type
var, mais ne fait que lire.
On dirait qu'il appartient à $sent_http_
variables uniquement.
J'ai aussi essayé "${sent_http_content_type}"
au lieu de $sent_http_content_type
avec le même résultat.
more_set_headers
ne résout pas ce problème.
Pourquoi Nginx se comporte-t-il ainsi ? S'agit-il d'un bogue ?
Edit :
L'exemple que j'ai fourni est juste le cas le plus simple où $sent_http_
les vars disparaissent. En fait, je veux faire quelque chose comme ça :
if ($sent_http_access_control_allow_origin ~ "^(https?)://([^/]+)") {
set $new_cors http://$1.$2.proxy.mydomain.com;
}
more_set_headers "Access-Control-Allow-Origin: $new_cors";
J'écris un serveur proxy et je dois remplacer Access-Control-Allow-Origin
car sinon les sites mandataires ne fonctionnent pas comme prévu.
Dans l'exemple ci-dessus if
(en server
) ne donne jamais true
même si un tel en-tête existe et qu'il correspond à mon expression régulière.
Peut-on y remédier ? Nous apprécions votre aide !
0 votes
if
a également été exécutée trop tôt pour vous.0 votes
@AlexeyTen, cela signifie-t-il qu'il est impossible de remplacer l'en-tête de réponse par une expression rationnelle ?
0 votes
C'est possible. Je vais modifier la réponse
0 votes
Il serait beaucoup plus facile d'utiliser le module Lua par exemple. De plus, vous devriez probablement utiliser
$upstream_http_*
variables.0 votes
J'ai mis à jour la réponse