[PATCH] ngx_conf_file: "include ./" acts relative to currently parsed file

[Maxim Dounin]

Hello!

On Tue, Sep 03, 2019 at 06:21:47PM +0200, Guillaume Outters wrote:

> Le 2019-09-03 16:39, Maxim Dounin a écrit :
> 
> >> include @example.conf;
> >> include example.conf local;
> >> include example.conf -l;
> >> include example.conf relative;
> >> include example.conf from_there;
> >> include example.conf nearby;
> > 
> > I can't say I like either of the variants.
> 
> … Neither do I (although the "nearby", that I submitted in my last 
> patch that you perhaps haven't read yet, seems the most natural one).
> 
> > Additionally, all variants with an additional explicit flags won't
> > work in other cases where a configuration prefix is currently
> > used, such as ssl_certificate or auth_basic_user_file.  On the
> > other hand, obviously enough it should be possible to resolve from
> > the current included file all paths which are currently resolved
> > from the configuration prefix.
> 
> The big difference between include and all other directives is that 
> include does not do variable resolution.
> 
> This allows the misuse of (request-time) variables to store absolute 
> paths, with things such as:
> map $http_host $app_root { default /var/www/app1; } # Or a set, or 
> $document_root/.., whatever.
> ssl_certificate $app_root/certs/thissite.pem;
> 
> This makes an unnecessary variable evaluation at runtime, but as it's 
> technically possible, and as such I'm quite certain there exists a ton 
> of such configurations in the world (if only to reduce typing, and thus 
> copy-paste errors).
> 
> But include has no such configurability.

There were no way to use variables in ssl_certificate till nginx 
1.15.9 released this year.  There are no variables support in the 
ssl_stapling_file directive and various other directives, such as 
ssl_client_certificate, ssl_ecdh_param, and so on.  Yet all these 
directives currently use consistent path resolution - from 
configuration prefix.  And preserving this consistency is 
important.  That's why don't like the idea to introduce yet 
another incompatible machanism to resolve file names.

> Both of these advocate in favor of config-time variables:
> - include would benefit of a bit of configurability:
>    webapps containing their nginx config could be dropped by a sysadm 
> wherever
>    he wanted, set a (config-time) $app_root, and the app would work out 
> of the
>    box by using $app_root to reference snippets indepently of where it 
> has been
>    put.
> - other directives (that for now misuse request-time variables) would 
> have a
>    clear separation between config-time resolved parts and request-time 
> ones,
>    with a performance gain on the config-time ones
> But this would require a bit of thinking (about where variables do get 
> stored
> during the config reading, do they persist until the request-time, 
> attached to
> each block with the last value they acquired during config reading, to 
> serve as
> default values for the request-time variables, and so on).

As http://nginx.org/en/docs/faq/variables_in_config.html mentions, 
it is more or less trivial to introduce configurations macros 
yourself.

> In the meantime (and who can tell the meantime's duration?), the 
> "nearby" keyword
> is a simple, semi-elegant placeholder for that.
> (Hum… in fact, even with a way to "setenv $app_dir; include 
> $app_dir/nginx/snippet.conf;",
> I think I would continue to just "include snippet.conf nearby;")

See above.  While it may be simple to implement (not really, as 
your patch misses at least a couple of module-specific "include" 
implementations), it is not that simple from consistency point of 
view.

-- 
Maxim Dounin
http://mdounin.ru/