nginx配置解析详解(三).docVIP

nginx配置解析详解(三) 继续上次的分析： ngx_http_core_location(ngx_conf_t*cf, ngx_command_t *cmd, void *dummy) 通过前面的分析，location部分的解析跟http和server是同样的道理。 来看下面两句: clcf = ctx->loc_conf[ngx_http_core_module.ctx_index]; clcf->loc_conf = ctx->loc_conf; ctx是在解析该location时生成的ngx_http_conf_ctx_t，自然它的main_conf和srv_conf都会继承上层，而在本层重新设置loc_conf，这里我们看到，在location的解析中 ngx_http_core_loc_conf_t结构(即clcf)的loc_conf成员会保存所有其他module的location配置，用到的时候引用方便。 这里还有几个要说一下的： clcf->exact_match：类似 location = / {}，所谓准确匹配。 clcf->noregex：没有正则，但不要求准确匹配，如/usr可以跟/usr/local算匹配 clcf->named：以’@’开头的，如location @test {} clcf->noname：nginx会把if 指令配置也看做一个location，即noname类型。 location中出现‘~’的，就认为是有正则的配置了，就会调用ngx_http_core_regex_location来处理，注意一点的是，这个函数的第三个参数是大小写标记，一般“~”是忽略大小写处理的，而“~*”是要考虑大小写的。 函数中会调用ngx_http_regex_compile来对正则表达式做处理，使用是PCRE库，具体的接口和原理，大家可以去PCRE官网去找一下。这个函数的一个重点在于它会把正则中出现的$1,$2…等，提取出代表的字符串作为一个” 参数”，放到全局的参数表中，供后面使用。关于nginx中的变量和脚本特性，会在配置解析这块分析完之后，做专门分析。 继续看： pclcf = pctx->loc_conf[ngx_http_core_module.ctx_index]; 这里是拿到上层的location（若有的话），来验证内嵌的location配置语法是否合法。 如果上层的location是准确配置的(即exact_match)或者带“@”的(named)，那么不允许内嵌location，还有内嵌的location不能为named，即带“@”的。如果这些检查通过，那么还要求内嵌的location 路径要跟上层的路径有公共前缀。 如： location /usr/ { location /usr/local/ { } } 来看这个函数：ngx_http_add_location 它涉及一个ngx_http_location_queue_t的结构， 即lq。一个location的配置，即代码里的clcf会通过这个结构保存，如果当前的location没有嵌套，那么它就是exact的，放在这个结构的exact，嵌套的放到结构的inclusive中。 看这一句：ngx_queue_insert_tail(*locations,&lq->queue); 大家应该明白它的意图，那就是内嵌在一个location中的各个location配置，会组成一个双向queue，挂在上层的配置结构locations成员里(即queue头)，如pclcf->locations。 从server配置的角度看，每遇到一个location，都会建立一个双向queue，没有内嵌的，也就只有它自己罢了。 location部分就做了这些事情，因为整个处理是一个递归过程，所以我们看看当解析完location，回到http处理时，还会做些什么。 回到函数ngx_http_block，我们前面说过了，当ngx_http_block中ngx_conf_parse返回的时候，意味着下层的server和locatio都已解析整理完毕了。好了，我们把最后的任务拿出来看下： cmcf = ctx->main_conf[ngx_http_core_module.ctx_index]; cscfp = cmcf->servers.elts; for (s = 0; s < cmcf->servers.nelts; s++) { clcf =cscfp[s]->ctx->loc_conf[ngx_http_core_module.ctx_index]; if(ngx_http_init_locations(cf, c