use

[António P. P. Almeida]

On 23 Jul 2011 17h17 WEST, gmm at csdoc.com wrote:

> On 23.07.2011 17:42, António P. P. Almeida wrote:
>
>>> Igor, likely nginx now need something like httpd mod_macro
>>> to eliminate multiple duplicates of small config fragments
>
>> I followed the discussion on the russian ML. Yes something like
>> your use suggestion would be great.
>
> that my message in russian ML:
> http://www.lexa.ru/nginx-ru/msg41221.html
>
> in that proposal I make one mistake: "local" site config files also
> includes in main nginx.conf config via include directive, for
> example
>
> include /etc/nginx/virtual/*.conf;
>
> and all blocks will have global scope after this include in
> nginx.conf now I can see only three solutions:
>
> 1. make two include-like directives, for example, 'include'
> and 'require' - one inherit blocks/macros from included files
> and one - not inherit.

Bear in mind that I've just browsed some begginer docs on Nginx
internals. But wouldn't that make the all process of merging the
configurations when inheriting handlers too complex?

> 2. make two block/macro-like directives, one with strict scope
> to one local config file and one - with scope extendible by include.
>
> 3. allow silently overwrite prevous defined macros (DANGEROUS)
>
> I think the best way for solution is two include-like directives:
> 'include' directive - leave intact, and new 'require' directive -
> do not import any block/macro definitions from included files.
>
> in this case - all 'global' include-files with block/macro
> definitions will be included in 'local' site configuration
> files via dumb include directive, and all 'local' site config
> files will be included in main nginx.conf via require directive:
>
> require /etc/nginx/virtual/*.conf;
>
> in this case - any 'local' site config file can have its own
> blocks/macros with same names, as in other 'local' site config
> files, and all errors with accidental macro redefinitions
> will be easy detected at phrase of nginx config parsing.
>
> and my original proposal also add to nginx third variant
> of include-like directive: 'use' - for block/macro substitution,
> like in mod_macro - http://www.cri.ensmp.fr/~coelho/mod_macro/
>
> ================================================================
>
> also httpd mod_macro is feature-rich - it have macro arguments.
> same feature can be implemented also for nginx. for example:
>
> define macro_name {...} - macro without arguments
>
> define macro_name( ARG1, ARG2, ARG3, ... ) {...} - macro with
> arguments
>
> 'define' - new nginx keyword instead of 'block' (as in original
> message) this is something like well known C-preprocessor #define
> directive.  because nginx have C-like syntax, not html-like, as
> apache one.

I would be happy with a "simple" define or defmacro that uses C like
syntax. I prefer defmacro just to distinguish it from the C
preprocessor directive. It avoids hypothetical confusions between C
source and Nginx configuration. 

defmacro static_images {
   ## For static images don't log 404s and make the expire be maximal.
   expires max;
   log_not_found off;
}

location ^~ /imgpool/ {
   location ~* /imgpool/.*\.(?:jpe?g|png|gif|ico)$ {
      static_images;
   } 
}

location ^~ /other/img/ {
   static_images;
}

The scope could continue to be global and thus it wouldn't touch on
the location configuration merge process and preserve all the current
capabilities of hooking into the multitude of aspects of nginx
processing cycle when writing a module.

Your proposal is great, but in the meantime a stopgap solution like
the above would be great. Potentially it can make the configurations
shorter, less prone to errors, and above all: avoid repetition.

--- appa