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
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel