Opened 3 days ago

Last modified 3 days ago

#2414 new enhancement

support unknown variables when it is only used in log format

Reported by: gentle-king@… Owned by:
Priority: minor Milestone:
Component: nginx-module Version: 1.21.x
Keywords: Cc:
uname -a: Linux cent82-2c4g 4.18.0-348.7.1.el8_5.x86_64 #1 SMP Wed Dec 22 13:25:12 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.21.4
built by gcc 8.5.0 20210514 (Red Hat 8.5.0-4) (GCC)
built with OpenSSL 1.1.1o 3 May 2022
TLS SNI support enabled
configure arguments: --prefix=/home/ngx/nginx --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_sub_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_auth_request_module --with-http_addition_module --with-openssl=/home/ngx/build_ngx/openssl-1.1.1o --with-zlib=/home/ngx/build_ngx/zlib-1.2.11 --with-pcre=/home/ngx/build_ngx/pcre-8.45

Description

currently, when we add some extend variable in log format which is not yet defined with "set" or other command, it will raise emerg error: unknown "xxxxxx" variable. so if you want change log field, depend on other config, server block, eg.

sometimes it is needed to extend variables in logs in batch, and the variable, is set only in some instance, and is not set in other instance.

it can be as $http_ or $arg_, even $http_xxxx variable is not found in head, it will not raising error when writing log, and not raise error when do test or reload.
for every variable, of only used in log format, just not raise error. or for specify variables, add similar way: $ngx_ext_ , eg.

Change History (1)

comment:1 by Maxim Dounin, 3 days ago

Note that $http_*, $arg_* and some other variables are special, as these variables lookup particular headers (or arguments) in the request. Since it is not possible to tell during a configuration parsing if a particular header will be available or not, these variables are always available.

For normal variables nginx knows if these are defined somewhere in the configuration or not, and can reject obviously invalid cases during configuration parsing. And this is what it does.

If for some reason you want to use a variable which is known to be never set in nginx configuration, consider providing a dummy set somewhere, so nginx won't complain. For example, set in an internal location which cannot be reached might be a good solution.

Note: See TracTickets for help on using tickets.