Directive inheritance

[Lucas Rolff]

Hi Francis,

Thank you a lot for your response - from a directive point of view - I 
don't use a lot of different headers in that sense, it's really just 
some settings that I would want to avoid repeating again and again - I 
like clean configs - and generally speaking I really want to inherit as 
much as possible from the initial server, or even http context when 
possible - all I change usually can be things like the expires header, 
the proxy_cache_valid directive, or adding an additional header (CORS 
for example).

I do use some of the openresty modules such as the ngx_headers_more 
module, and it's pretty explicit about it's inheritance.

And thank you for the pointer regarding the _module_ctx and 
_merge_loc_conf functions, it gave me enough information regarding the 
http_proxy module as an example - it seem as long as there a 
"offsetof(ngx_http_proxy_loc_conf_t" - then it can be inherited, or it's 
a coincidence that it's missing the "offsetoff" for all directives that 
doesn't inherit in that module from top of my head.

Thanks again!


Francis Daly wrote:
> On Fri, Oct 06, 2017 at 07:32:51PM +0000, Lucas Rolff wrote:
>
> Hi there,
>
>> I know that there’s some settings such as proxy_pass which can’t inherit from the parent location or server block, however – is there any semi-easy way to figure out if a directive in nginx or it’s modules gets inherited or not? (I don’t mind digging around in some nginx source code)
>
>> I wonder if someone either knows a good way to figure out, or any document on the web that goes extensively into explaining what (might) inherit based on general design patterns.
>
> My quick response, without doing too much research, is:
>
> * "rewrite" module directives (if, return) don't inherit
> * "handler" directives (proxy_pass, fastcgi_pass) don't inherit
> * pretty much anything else that is valid in "location" does inherit
>
> (That's probably not correct, but could be a good starting point for
> experimentation.)
>
> And be aware that inheritance is by replacement, or not at all -- so one
> "add_header" in a location means that the only "add_header" relevant
> to that location is the one that is there; while no "add_header" in a
> location means that all of the ones inherited from server{} are relevant.
>
>
> If you want the full details, it's a matter of Read The Fine Source --
> each module has a "_module_ctx" which includes a function typically named
> "_merge_loc_conf" which shows how each directive is set if it is not
> defined in this location: unset, set to a default value, or inherited
> from the previous level.
>
> 	f

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20171006/2b404c60/attachment-0001.html>