support unknown variables when it is only used in log format

[gentle-king@…]

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.

[Maxim Dounin]

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.

[gentle-king@…]

Replying to Maxim Dounin:

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.

There are many nginx instances used by different user.
And they have same log format, mantained by manager, if manager want add field, need inform users to add "set" first, it is not easy.

so, in this scenario, it is better to support unknown variable or a similar as $http_ in log format.

[Maxim Dounin]

As long as the log format is maintained somehow, there should be a way to maintain appropriate set directives as well.

Another (and probably less intrusive that using set) approach to define variables would be to provide some regular expression with appropriate variables. For example, at the same level as log_format this can be done with a map:

map dummy $dummy { ~(?<foo>)(?<bar>)(?<bazz>) dummy; }
log_format test "$foo $bar $bazz";

While we can consider a more natural way to define variables, I don't think that allowing arbitrary unknown variables is a way to go.

[Maxim Dounin]

As per previous comments, closing this.