Nginx配置文件解析之二

xiahe999

　　这一部分，我们看看nginx怎样来组织http block，server block和location location的。
　　1、 ngx_http_block(ngx_conf_t *cf, ngx_command_t *cmd, void *conf)
　　首先设置一个ngx_http_conf_ctx_t结构，即ctx。
　　typedef struct {
　　void **main_conf;
　　void **srv_conf;
　　void **loc_conf;
　　} ngx_http_conf_ctx_t;
　　在分析这个结构中成员的作用时，先来看这样一个结构：
　　typedef struct {
　　ngx_int_t(*preconfiguration)(ngx_conf_t *cf);
　　ngx_int_t(*postconfiguration)(ngx_conf_t *cf);
　　void *(*create_main_conf)(ngx_conf_t*cf);
　　char*(*init_main_conf)(ngx_conf_t *cf, void *conf);
　　void*(*create_srv_conf)(ngx_conf_t *cf);
　　char*(*merge_srv_conf)(ngx_conf_t *cf, void *prev, void *conf);
　　void *(*create_loc_conf)(ngx_conf_t*cf);
　　char*(*merge_loc_conf)(ngx_conf_t *cf, void *prev, void *conf);
　　} ngx_http_module_t;
　　各个module可以根据需要设置这些函数指针。这些函数有他们各自的用途，create开头的主要是创建该module需要使用的结构体等等。
　　再看ngx_http_conf_ctx_t结构，这个结构体中的三个成员都是二级指针。实际上，各个module中create开头的函数都会创建module的配置结构，将得到的结构指针放到相应的数组中，如create_main_conf返回的指针会放到ctx->main_conf中，create_srv_conf返回的指针会放到ctx->srv_conf中。当然了这里会先对所有属于NGX_HTTP_MODULE的模块进行计数。
　　接下来，我们会先临时保存一下cf，因为在后面的递归解析时，cf的一些成员会被更改，而当返回的时候，原来的cf还要继续用。
　　pcf = *cf;
　　cf->ctx = ctx;
　　我们看这个preconfiguration，即ngx_http_module_t中的第一个函数指针。它的作用是什么？
　　当查看ngx_modules数组的时候，会发现下面几个module设置了preconfiguration：
　　ngx_http_core_preconfiguration (实际上调用了ngx_http_variables_add_core_vars)，
　　ngx_http_upstream_add_variables，
　　ngx_http_proxy_add_variables，
　　ngx_http_browser_add_variable
　　说白了，这四个函数主要是在开始后面的解析之前，设置一些变量，来为后用(主要是在脚本解析编译的时候)。我们看到的是，他们依次设置了这么几个变量(即，全局数组)：
　　ngx_http_core_variables，ngx_http_upstream_vars，ngx_http_proxy_vars，ngx_http_browsers。具体内容大家可以自己去读下代码，这些信息都是后面解析可能会用到的，这也就是preconfiguration中pre前缀的意思了！
　　接下来这两句告诉我们，下面要解析的内容是只涉及http相关module，而且其配置的指令是直接出现在http block中，而非server或者location，即所谓的MAIN_CONF。
　　cf->module_type = NGX_HTTP_MODULE;
　　cf->cmd_type = NGX_HTTP_MAIN_CONF;
　　当下面这句返回的时候，整个解析就结束了，这也体现了递归的特点！
　　rv = ngx_conf_parse(cf, NULL);
　　这里先进到递归过程的内部，出来之后我们再看后面的处理。
　　进入ngx_conf_parse之后，会遇到“server”，然后会调用ngx_http_core_server处理server block的配置。
　　2、 ngx_http_core_server(ngx_conf_t *cf, ngx_command_t *cmd, void*dummy)
　　首先会创建一个ngx_http_conf_ctx_t结构，我们知道http block中可能会配置多个server，这样ngx_http_core_server也就被调用多次，我们后面会看到这些ngx_http_conf_ctx_t，即ctx，在各层之间建立一系列复杂的关系。
　　看下面这两句，server里面的ctx->main_conf指向http ctx的main_conf，这么做的原因很简单，block 的main_conf在各个server公用的，这里只是继承上层的main_conf配置。
　　http_ctx = cf->ctx;
　　ctx->main_conf = http_ctx->main_conf;
　　接下来会出现跟http block处理中相似的一幕，ctx->srv_conf和ctx->loc_conf分别得到了初始化。这里大家应该意识到location block中肯定也会有相似的一幕，呵呵！
　　我们看到有这样的一个层次：http->server->location，在每个层次的处理时，都会创建一个ctx(即ngx_http_conf_ctx_t)，然后它会继承上层的配置，只处理属于自己层次的东西，如location block中的ctx，srv_conf和main_conf都会继承上层的，而loc_conf则会在当前被设置。
　　后面会很多次的使用ngx_http_core_module，毕竟接下来的都是http配置的处理。
　　接下的几句比较好理解，有几点需要强调一下。
　　cscf->ctx = ctx; //这样在解析server部分的时候，就可以很方便的引用上层和下层的配置。
　　cmcf->servers; // main_conf中的servers是一个数组，httpblock中配置的各个server，都会作为数组成员放到里面.
　　后面的处理跟http block中的类似，进入到server{}的里面，继续解析，并将处理location的
　　配置。在ngx_conf_parse返回之后，若发现没有配置listen，那么nginx会这设置默认的。
　　先说一下，location的解析是整个配置解析里面最复杂的，下次会单独展开来讲。