From: Eran Kornblau Sent: Monday, March 6, 2017 9:53 PM To: firstname.lastname@example.org Subject: Add support for 'define' directive
I would like to add support for a 'define' directive to nginx, which will allow text substitutions during conf parsing. At this point I'm thinking about adding support only for simple macros - no parameters, no ifdefs etc. Before I start working on the code, I wanted to check whether this makes sense to you and whether you'll be willing to merge it (assuming it's implemented well, of course).
A sample configuration may look like this: nginx.conf: ... define extra_log_args '$http_my_param $arg_some_arg' ... include child.conf
child.conf: ... log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $bytes_sent $request_time "$http_referer" ' %extra_log_args%; ...
In terms of implementation, the define command will add the key/value to a new rbtree on ngx_conf_t. In ngx_conf_read_token, next to the code that decodes \r,\n etc., the defined keys will be expanded to their values. Since the expansion is performed within an arg, this implies that a define cannot map to multiple args - it will essentially be like an nginx variable except that it's evaluated during conf parsing.
An example of a use case where this could be useful (from our production environment) - We have multiple types of nginx servers, for example, some serve vod content, and some serve live video content. In addition to that, we have multiple data centers. The configuration of these servers is different but there are many common parts. Our way to share these common parts is to create small shared conf files and have them included by the server-specific configuration files. So we have <server types>x<sites> root conf files that include other files. On each server, nginx.conf is a symbolic link to the root conf matching the specific server. In some cases, some internal conf file has parts that depend on the site, and the problem is that we don't have a way to propagate the id of the site from the root conf to this child conf. We can probably do it with 'set', but that would be less optimal since there's no reason to have this value dynamic.
Any feedback is welcome