nginx框架---配置文件ngx_conf_handler函数

最新推荐文章于 2024-07-18 00:08:52 发布
最新推荐文章于 2024-07-18 00:08:52 发布
阅读量401 收藏 1
点赞数 1
分类专栏： nginx 源码阅读 文章标签： nginx 数据结构 c语言
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/dai1396734/article/details/126125518
版权
在上代码之前先做点铺垫，做下简单解释，这样更方便理解源码
在调用ngx_conf_handler前，已经调用了ngx_conf_read_token将配置项信息放入到了cf->args中了，所以能从里面拿到配置项的名称和值
函数逻辑很简单，分为以下几步：
  1. cf->args找到配置项名字
  2. 然后遍历模块，每个模块继续遍历其配置项，找到模块指定配置项指针（ngx_command_t *commands）
  3. 调用其set(函数);
遍历过程对模块不太熟悉的可以看看

ngx_module_t

重点描述下ngx_command_s 的type，也就是配置类型，借用《深入理解nginx模块开发与架构解析》的图

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

下面是源码（带注释）
static ngx_int_t
ngx_conf_handler(ngx_conf_t *cf, ngx_int_t last)
{
    char           *rv;
    void           *conf, **confp;
    ngx_uint_t      i, found;
    ngx_str_t      *name;
    ngx_command_t  *cmd;
	//cf->args->elts 不是包含了配置项的名字和值吗？为什么可以取到名字？
    //因为cf->args->elts是一个链表，首节点就是配置项名字，并且每个元素都以'\0'结尾了
    name = cf->args->elts;

    found = 0;
    //遍历模块
    for (i = 0; cf->cycle->modules[i]; i++) {

        cmd = cf->cycle->modules[i]->commands;
        if (cmd == NULL) {
            continue;
        }
        //遍历模块的配置项
        for ( /* void */ ; cmd->name.len; cmd++) {

            if (name->len != cmd->name.len) {
                continue;
            }
            //匹配配置项的名字
            if (ngx_strcmp(name->data, cmd->name.data) != 0) {
                continue;
            }

            found = 1;

            if (cf->cycle->modules[i]->type != NGX_CONF_MODULE
                && cf->cycle->modules[i]->type != cf->module_type)
            {
                continue;
            }

            /* is the directive's location right ? */
            //匹配配置项的类型
            if (!(cmd->type & cf->cmd_type)) {
                continue;
            }
            //不是块配置项 又没找到字符";"
            if (!(cmd->type & NGX_CONF_BLOCK) && last != NGX_OK) {
                ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
                                  "directive \"%s\" is not terminated by \";\"",
                                  name->data);
                return NGX_ERROR;
            }
            //是块配置项又没找到字符"{"
            if ((cmd->type & NGX_CONF_BLOCK) && last != NGX_CONF_BLOCK_START) {
                ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
                                   "directive \"%s\" has no opening \"{\"",
                                   name->data);
                return NGX_ERROR;
            }

            /* is the directive's argument count right ? */
            //排除参数个数与配置项要求不符合的情况
            if (!(cmd->type & NGX_CONF_ANY)) {

                if (cmd->type & NGX_CONF_FLAG) {

                    if (cf->args->nelts != 2) {
                        goto invalid;
                    }

                } else if (cmd->type & NGX_CONF_1MORE) {

                    if (cf->args->nelts < 2) {
                        goto invalid;
                    }

                } else if (cmd->type & NGX_CONF_2MORE) {

                    if (cf->args->nelts < 3) {
                        goto invalid;
                    }

                } else if (cf->args->nelts > NGX_CONF_MAX_ARGS) {

                    goto invalid;

                } else if (!(cmd->type & argument_number[cf->args->nelts - 1]))
                {
                    goto invalid;
                }
            }

            /* set up the directive's configuration context */

            conf = NULL;
            
            if (cmd->type & NGX_DIRECT_CONF) {
                conf = ((void **) cf->ctx)[cf->cycle->modules[i]->index];

            } else if (cmd->type & NGX_MAIN_CONF) {
                conf = &(((void **) cf->ctx)[cf->cycle->modules[i]->index]);

            } else if (cf->ctx) {
                confp = *(void **) ((char *) cf->ctx + cmd->conf);

                if (confp) {
                    conf = confp[cf->cycle->modules[i]->ctx_index];
                }
            }

            rv = cmd->set(cf, cmd, conf);

            if (rv == NGX_CONF_OK) {
                return NGX_OK;
            }

            if (rv == NGX_CONF_ERROR) {
                return NGX_ERROR;
            }

            ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
                               "\"%s\" directive %s", name->data, rv);

            return NGX_ERROR;
        }
    }

    if (found) {
        ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
                           "\"%s\" directive is not allowed here", name->data);

        return NGX_ERROR;
    }

    ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
                       "unknown directive \"%s\"", name->data);

    return NGX_ERROR;

invalid:

    ngx_conf_log_error(NGX_LOG_EMERG, cf, 0,
                       "invalid number of arguments in \"%s\" directive",
                       name->data);

    return NGX_ERROR;
}
上诉源码内容有注释，不做多解释，下面代码可能看起来可能会有点晕，我描述下自己的理解，
 			if (cmd->type & NGX_DIRECT_CONF) {
                conf = ((void **) cf->ctx)[cf->cycle->modules[i]->index];

            } else if (cmd->type & NGX_MAIN_CONF) {
                conf = &(((void **) cf->ctx)[cf->cycle->modules[i]->index]);

            } else if (cf->ctx) {
                confp = *(void **) ((char *) cf->ctx + cmd->conf);

                if (confp) {
                    conf = confp[cf->cycle->modules[i]->ctx_index];
                }
            }

            rv = cmd->set(cf, cmd, conf);
cf->ctx 是一个void****指针，就是全局变量cycle的指针
struct ngx_cycle_s {
    void                  ****conf_ctx;
	....    
}
根据配置项类型，来取出其在conf_ctx结构体中的位置

1、当类型是包含NGX_DIRECT_CONF时，"{}"外的配置，conf =((void **) cf->ctx)[cf->cycle->modules[i]->index];

2、当类型是包含NGX_MAIN_CONF时， "{}"外的配置，conf = &(((void **) cf->ctx)[cf->cycle->modules[i]->index]);

有什么区别呢？你可以把((void *) cf->ctx)[cf->cycle->modules[i]->index]当做下图标红的void，区别如下图
在这里插入图片描述

3、当类型不是上诉2种呢？"{}"内的配置，这里的cf->ctx 值已经被更改过了，会指定到结构体上去了

	confp = *(void **) ((char *) cf->ctx + cmd->conf);
    if (confp) {
        conf = confp[cf->cycle->modules[i]->ctx_index];
    }

在这里插入图片描述

为什么指针会这样取？继续讨论，当根据类型取出适当位置的结构体指针后，就调用了下面代码
 	rv = cmd->set(cf, cmd, conf);

顾名思义应该是用来设置配置结构体的，是否真是这样，举例说明：

1、ngx_core_module，下图右边红框标示就是其set函数，由于其类型是NGX_DIRECT_CONF，是核心模块，配置结构体一开始就已经分配好了，也就是conf 所指向的结构体，所以只需要设置其配置结构体的值就好了
在这里插入图片描述
2、ngx_http_module,其类型是NGX_MAIN_CONF,其set接口是 ngx_http_block
详情可参考ngx_http_block
在这里插入图片描述
在该函数内部为conf 分配了内存，代码如下：

static char *
ngx_http_block(ngx_conf_t *cf, ngx_command_t *cmd, void *conf)
{
	...
	ngx_http_conf_ctx_t         *ctx;
	...
	ctx = ngx_pcalloc(cf->pool, sizeof(ngx_http_conf_ctx_t));
	...
    *(void **) conf = ctx;
    ...
    cf->ctx = ctx;
}

为了让void*指向ngx_http_conf_ctx_t结构体，conf取数只能如下形式

conf = &(((void **) cf->ctx)[cf->cycle->modules[i]->index]);

在这里插入图片描述
3、ngx_http_core_module，既不是NGX_MAIN_CONF 也不是NGX_DIRECT_CONF，set 接口的内容也是设置值了，不过多描述

在这里插入图片描述
这里说下conf 的取值，为什么要先取confp

confp = *(void **) ((char *) cf->ctx + cmd->conf);
if (confp) {
    conf = confp[cf->cycle->modules[i]->ctx_index];
}

这里要注意的是此时cf->ctx在 上诉第2个过程已经更改值了，直接指向了ngx_http_conf_ctx_t结构体如下图所示
在这里插入图片描述
在看下ngx_http_conf_ctx_t定义，cmd->conf就是结构体成员所在的位置，根据confp = *(void **) ((char *) cf->ctx + cmd->conf);
就能知道是哪一个结构体成员，然后根据ctx_index（同级子模块所在的索引）找到指定配置结构体

typedef struct {
    void        **main_conf;
    void        **srv_conf;
    void        **loc_conf;
} ngx_http_conf_ctx_t;
至此基本将配置文件的内容设置进来内存，也就是全局变量cycle 的 ***conf_ctx成员
dai1396734
关注
  • 1
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
ngx_conf_parse函数
simply the best
01-26 3618
这里要先看一下配置文件格式: worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_ti
nginx的配置加载
lswdcyy的博客
07-05 1767
nginx-1.22编写nginx模块的时候，有个数据结构，就是ngx_module_t数据结构，这个数据结构是整个模块的核心，本篇文章主要针对一般性的配置(http块配置)的整个加载过程，以及在整个加载配置过程中ngx_module_t中各个回调函数的意义。首先说一下总体的加载过程模型，就是从配置文件中逐个字符进行扫描，然后扫描到一组配置或者一个配置块就进行配置解析，再次过程中进入不同配置块，会切换解析状态，如一开始最外层的解析NGX_CORE_MODULE模块配置，然后遇到http块进入http块配置就
nginx源码分析--配置文件解析
鱼思故渊的专栏
04-26 1264
Nginx的配置解析相关的部分比较绕，比如为何要有4重指针，比如NGX_MAIN_CONF ， loc_conf,NGX_DIRECT_CONF有什么区别呢?这些我前面的blog都有些涉及，这次主要是把配置这块完全拿出来然后来分析下。 首先来看配置解析时的数据结构，这里主要是ngx_conf_t，这个结构保存了解析配置文件所需要的一些域，这个是非常重要的一个数据结构，我们详细来看这个结构： s
详解Nginx的配置函数对于请求体的读取
09-30
主要介绍了Nginx的配置函数对于请求体的读取,深入Nginx的内核配置中进行讲解,需要的朋友可以参考下
Nginx-------配置文件解析ngx_conf_handler
jackywgw的专栏
09-28 1919
(1)  NGX_DIRECT_CONF if (cmd->type & NGX_DIRECT_CONF) { ngx_conf_log_error(NGX_LOG_DEBUG, cf, 0,"NGX_DIRECT_CONF"); conf = ((vo
nginx基本配置与参数说明
weixin_34115824的博客
03-11 223
user nobody;#启动进程,通常设置成和cpu的数量相等worker_processes 1;#全局错误日志及PID文件#error_log logs/error.log;#error_log logs/error.log notice;#error_log logs/error.log info;#pid logs/nginx.pi...
Nginx学习（6）—— handler模块（自定义handler配置模块的编码编译）
Stars____的博客
03-27 1089
Handler模块就是接受来自客户端的请求并产生输出的模块。配置文件中使用location指令可以配置content handler模块，当Nginx系统启动的时候，每个handler模块都有一次机会把自己关联到对应的location上。如果有多个handler模块都关联了同一个location，那么实际上只有一个handler模块真正会起作用。所以在开发阶段应该避免多个handler模块关联同一个location的情况发生。handler模块处理的结果通常有三种情况处理成功。
nginx上传下载之nginx-upload-module-2.3.0
10-15
接下来，你需要编辑 Nginx 的配置文件（通常位于 `/etc/nginx/nginx.conf` 或 `/usr/local/nginx/conf/nginx.conf`），添加对 Nginx Upload Module 的支持。首先备份原配置文件： ```bash sudo cp /etc/nginx/nginx...
reading-code-of-nginx-1.9.2_y123456yz.tar.gz
10-20
7. **配置解析**：Nginx的配置文件解析由`ngx_conf_file`模块完成，`ngx_conf_parse`函数逐行读取配置并解析。 三、源码注释与学习方法 该压缩包包含详尽的函数中文注释，这对于初学者来说是一份宝贵的资源。学习...
ngx_http_mytest_module.zip_nginx_world
09-22
3. **解析配置指令**：使用`ngx_conf_handler_t`函数指针类型定义配置指令处理器，如`ngx_http_mytest_module_set_config`，处理在nginx配置文件中出现的自定义指令。 4. **注册模块**：在模块的初始化函数中，使用...
nginx-1.0.14_comment_jianfengye.tar.gz
10-20
此外，源码中还包含了配置文件解析的代码，如 `ngx_conf_parse` 函数，它读取 nginx.conf 文件并解析配置指令。这个过程涉及到配置项的合并、继承和覆盖规则，注解将详细解释这些过程。 对于开发者而言，这份带有...
cpp-nginx192源码通读分析注释
08-16
`src/core/ngx_conf_file.c`中的`ngx_conf_parse()`函数负责解析配置文件，将配置指令转换为结构化的数据，存储在`ngx_command_t`结构体中。配置指令的执行则由`ngx_conf_merge()`和`ngx_conf_handler()`完成。 5....
Nginx 入门指南（四）
猿人启示录
08-06 210
Nginx 的配置系统 Nginx 的配置系统由一个主配置文件和其他一些辅助的配置文件构成。这些配置文件均是纯文本文件，全部位于Nginx 安装目录下的 conf 目录下。 配置文件中以#开始的行，或者是前面有若干空格或者 TAB，然后再跟#的行，都被认为是注释，也就是只对编辑查看文件的用户有意义，程序在读取这些注释行的时候，其实际的内容是被忽略的。 由于除主配置文件 nginx.conf ...
nginx的结构体 ngx_conf_t
weixin_33816821的博客
08-09 1624
2019独角兽企业重金招聘Python工程师标准>>> ...
ngx_conf_read_token函数
simply the best
01-26 2949
当解析配置文件时候,会构造一个buf,来存放从配置文件中读取的数据. 每次解析出一组相关token就会返回. 1.遇到{表示遇到复杂配置,需要循环调用ngx_conf_read_token解析函数. 2.遇到;表示解析简单配置完毕,进行下一组解析. 3.遇到错误. buf大小为4096bty,即4k.一个buf中数据为四种: 未解析字符:已经读入buf中,但是还未进行扫描 已扫描字符
nginx的函数调用
yizhiniu_xuyw的专栏
05-23 525
1.找到nginx的工作进程 ps aux |grep nginx 2.使用 pstack 查看函数调用 pstack 5439 #0 0x00007f7ca5aa8903 in __epoll_wait_nocancel () from /lib64/libc.so.6 #1 0x000000000043710d in ngx_epoll_process_events (cycle=0x95a480, timer=18446744073709551615, flags=1) at src/.
Nginx 全局变量函数、正则、匹配的优先级
weixin_42655280的博客
12-07 417
在运维的世界中，掌握全局变量函数、正则表达式和匹配优先级，就如同掌握了一种语言的语法规则。Nginx，作为一款高性能的Web服务器，其全局变量函数、正则表达式和匹配优先级的理解与运用，更是每一位运维者必备的技能。
从零开始学数据结构系列之第四章《prim算法（普里姆算法）详解》
最新发布
铁匠匠匠的博客
07-18 1058
可以参考以下视频。
Nginx 模块 - ngx_core_module
05-17
ngx_core_module 是 Nginx 的核心模块，它提供了 Nginx 的基本功能，如配置文件解析、事件处理、进程间通信等。在 Nginx 启动时，ngx_core_module 会被首先加载。 ngx_core_module 的主要功能包括： 1. 配置文件解析：ngx_core_module 负责解析 Nginx 的配置文件，并将配置文件中的指令转化为 Nginx 内部结构体表示。 2. 事件管理：ngx_core_module 提供了事件管理器，负责监听套接字、定时器等事件，并将事件交给相应的模块处理。 3. 进程间通信：ngx_core_module 提供了进程间通信机制，可以用于多进程协同工作，如 master 进程与 worker 进程之间的通信。 4. 日志管理：ngx_core_module 提供了日志管理器，用于记录 Nginx 的运行日志。 5. 内存管理：ngx_core_module 提供了内存管理器，用于管理 Nginx 的内存分配和释放。 除此之外，ngx_core_module 还提供了一些基本的指令，如 worker_processes、worker_cpu_affinity 等，用于控制 Nginx 的进程数和 CPU 亲和性等。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

dai1396734

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值