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

[Guillaume Outters]

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.

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).

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;")

-- 
Guillaume