nginx源代码分析--配置信息的继承&合并

这里仅仅讲述http{}模块下的配置：

在ngx_http_block()函数内（这个函数别调用时在ngx_inti_cycle内的ngx_conf_parse函数，这个函数遇到http命令时 回调ngx_http_block。开启http{}配置块的解读工作），针对每个http模块。调用init_conf之后，有调用了ngx_http_merge_servers()。

这是为何！

首先明白几点：一个http{}配置块内能够包括多个server{}配置块，每一个server{}配置块能够包括多个location{}配置块，每一个location{}配置块能够嵌套location{}配置块。把每一个使用{}包括起来的配置块称为一个层次。在ngx_http_block中调用ngx_conf_parse时，还调用了ngx_http_core_server和ngx_http_core_location 这两个函数是解析server{}块和location{]块的。

在不同的层次为同一个http模块创建了存储配置的结构体空间。比方在http{}层次为某一个http模块创建了
main_conf、srv_conf、loc_conf配置，在ngx_http_core_server内为同一个http模块创建了srv_conf loc_conf配置，在ngx_http_core_location函数内为同一个http模块创建了loc_conf配置。可是这是不同层次上的配置。对于某一个http模块中的某一个命令来说，它可能出现的区域有http{} server{} locaton{},假设在某一个server{}块内没有这个命令 那么它就须要从http{}中继承这个命令，假设某个server{}中存在这个命令，那么就不须要从http{}中继承；假设server{}中的某一个location{}中没有这个命令，那么就须要从上层（server{}层或者location{}层）继承，假设上层没有，直接从http{}中继承，或者使用默认。整个继承的流程如上所述。对于某一个http模块中的命令能够出现的层次是它本身自己知道的，怎么合并（使用函数merge_srv_conf和

merge_loc_conf函数回调）也是模块本身定义的。

正是模块中命令能够出如今不同区域才造成了继承合并的操作，这也是为了配置文件的灵活。

解析流程：在ngx_http_block函数中。

一个for循环为每个http模块调用init_main回调和ngx_http_merge_servers.

在ngx_http_merge_servers中一个for循环 须要遍历全部的server{}配置块。首先回调调用merge_srv_conf，从http上下文继承srv_conf配置。然后回调调用merge_loc_conf，从http上下文继承loc_conf配置，然后处理这个server{}块下的全部location{}块 调用ngx_http_merge_location

在ngx_http_merge_location中，首先从上文（server{]或者location{}）继承loc_conf配置 然后处理location{]模块下的全部loction{}