using variables in nginx.conf with 'set'

Arthur Blake arthur.blake at
Fri Oct 22 23:16:02 MSD 2010

Yes, I thought about using an external macro processor to achieve the
desired effect, but was hoping I could do without that.

So you are saying that even though it works for the $rootfolder in my
example, it is setting it to that value on each request.  Which is using it
in an unintended and inefficient way?


On Fri, Oct 22, 2010 at 11:40 AM, Maxim Dounin <mdounin at> wrote:

> Hello!
> On Fri, Oct 22, 2010 at 08:27:52AM -0400, Arthur Blake wrote:
> > It seems like the set command was designed for use in a narrow set of
> > circumstances.  But I think it would be a lot more useful if the
> variables
> > it defines could be used globally with any directive.
> >
> > I am trying to use the 'set' command in order to define my own variables
> > that define things that may vary by server in a main nginx.conf file so
> that
> > a generic reusable include file can later use those variables.  It seems
> > that the variables only work in certain places with certain directives.
> In nginx, variables are not something which "may vary by server", it's
> something which is request-specific and evaluated at runtime.
> Something which vary on per-server basis (usually referred as
> "configuration macros" here) isn't present in nginx at all.
> Consider using your favorite template engine (e.g. make + sed) or
> try server-specific includes.
> > Is there a reason I can't use variables set this way more widely?  I
> would
> > like to be able to use variables like this anywhere in the config files.
> >
> > In the example below, I define two variables with the 'set' command,
> > $rootfolder and $backend.
> >
> > The $rootfolder variable doesn't work with the include directive and the
> Include directives are evaluated during configuration parsing on
> server startup.  There is no request being processed, and no
> variables.
> > $backend doesn't work with the proxy_pass directive.
> Actually it does (since 0.6.18).  Though this requires resolver to
> be defined and implies address parsing and resolving if backend
> address given as domain name.  Additionally, it has another
> semantics than normal proxy_pass - with variables you have to
> specify full url of the resource to request (or only server,
> 0.8.25+), semantics of "proxy_pass with URI" doesn't apply.
> Maxim Dounin
> p.s. Just to summarise the above: you don't need variables, you
> need configuration macros.  These aren't implemented, but you are
> free to use your favorite template engine.
> _______________________________________________
> nginx mailing list
> nginx at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx mailing list