Add support for 'define' directive

[Eran Kornblau]

Ping

Eran

From: Eran Kornblau
Sent: Monday, March 6, 2017 9:53 PM
To: nginx-devel at nginx.org
Subject: Add support for 'define' directive

Hi all,

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

Thank you

Eran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20170312/7bdff1f8/attachment.html>