Variables in different contexts are mixed together

[alexgit2k@…]

Variables in different contexts are mixed together for the syntax-check.

Reproduceable with the nginx-Docker image:

docker run -it --rm nginx:latest /bin/bash

• Incorrect config with missing variable

  # cat <<EOT > /etc/nginx/conf.d/server1.conf
  server {
      listen       80;
      server_name  server1;
  
      rewrite /helloworld https://www.example.com/\$target;
  }
  EOT
  
  # nginx -t 
  nginx: [emerg] unknown "target" variable
  nginx: configuration file /etc/nginx/nginx.conf test failed
  

Expected error-message because variable target is not set.

• Correct config with same variable set

  # cat <<EOT > /etc/nginx/conf.d/server2.conf
  server {
      listen       80;
      server_name  server2;
  
      set \$target bar;
      rewrite /foo https://www.example.com/\$target;
  }
  EOT
  
  # nginx -t 
  nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
  nginx: configuration file /etc/nginx/nginx.conf test is successful
  

Unexpectedly no error-message for server1.conf + server2.conf together, because the variable set in server2.conf is wrongly used also for server1.conf

Note: A request to server1/helloworld correctly redirects to www.example.com/ (and not www.example.com/bar)

[Maxim Dounin]

Variables are global, and a variable defined anywhere in the http module is therefore known to nginx and won't produce errors during configuration parsing. For example, such variables can be used in various global entities, such as during logging defined at the http level. Similarly, variables defined at the http level, such as with ​map, can be used anywhere.

While this approach is unable to catch configuration errors like the one in your example during configuration parsing, it makes it possible to keep the code clean and simple.

To simplify catching of such configuration errors, nginx instead provides a runtime warning by default if a variable from the http rewrite module (created with set) is used but not set in the particular request handling path, see ​uninitialized_variable_warn.