Reading and practice of "deep understanding Nginx" (ii) use of configuration items

The completion of HelloWorld means to have entered the gate of Nginx, although very inspiring, but there are still many doubts in the writing: how each parameter in the NGINX.CONF configuration item is read into the program? ngx_command_t How do I complete the read work of a configuration item? How do conflicts for configuration items with the same name be resolved? Why is ngx_http_module_t in HelloWorld called the context of a module? At the same time, I read the 4th chapter "Use of configuration Items" and there are stereotypes: is not a variety of trivial parameter settings, what is good to read? (This stereotype comes from a chapter in UNP.) but after reading and practicing this section, I found it completely Bishi the point. In fact, the use of configuration items here refers to the process of passing the parameters of the configuration item that we set up in nginx.conf to the Nginx program. At the same time, after this chapter, you will learn how to turn a module "return HelloWorld according to the user's request URI" into a "module that can complete the parsing of various nginx configuration items."

Data structure that holds the value of a configuration item

Let's look at the data structure of the saved configuration parameters described in the article ngx_http_mytest_conf_t:

typedef struct {
    ngx_str_t       my_str;
    ngx_int_t       My_num;
    ngx_flag_t      My_flag;
    size_t          my_size;
    ngx_array_t*    My_str_array;
    ngx_array_t*    My_keyval;
    off_t            My_off;
    ngx_msec_t      my_msec;
    time_t          my_sec;
    ngx_bufs_t      My_bufs;
    ngx_uint_t      my_enum_seq;
    ngx_uint_t      My_bitmask;
    ngx_uint_t      my_access;
    ngx_path_t*     my_path;
} ngx_http_mytest_conf_t;
    
ngx_http_mytest_conf_t

Unlike the problems mentioned in the original book (Why not use global variables to store them), my question is, why not use a union to save space if you want to unify all kinds of configuration items such as integers, tokens (not 0, 1), strings, time, and so on, in a single structure? Continue reading with doubt: The data structure here is defined to allow for a later description of the default configuration item resolution method, and the configuration item it can handle is the following form:

name [ngx_str_t] [ngx_int_t] ... [ngx_path_t*] [[ngx_str_t][ngx_int_t]]

The name of this configuration item can be followed by 14 parameters and the 2 parameters of the Myconfig defined in the following text, all of which can appear in all or only one of these 16 parameters. In other words, its function is not only to deal with configuration item name + single parameter configuration items, but all possible forms of configuration items. This complexity is inevitable, if the actual use of the configuration items we can control a limited number of, no need to design so complex, as in HelloWorld mytest configuration items, there is no value at all, just set up an encounter that configuration item to start the MyTest module function just, It was not even necessary to design such a structure to hold the value of the configuration item.

Operation of the value of the configuration item: Reading and Merging

Looking back at the ngx_http_module_t structure that represents the context of a module in HelloWorld, the module has its own characteristics, although it was mentioned as the context of the module, but it was not a good thing to set its 8 callback methods to null. At this time, "deep understanding of Nginx" to it made a review and explained that I understand this: the so-called "above", is to do preconfiguration work, processing nginx.conf configuration items (all configuration items read into, set up data structure preservation, all levels of the same configuration item merge); " The following "is called function postconfiguration after processing the configuration item to do some follow-up work.

Static ngx_http_module_t  Ngx_http_mytest_module_ctx =
{
    NULL,//                              * preconfiguration * *
    NGX_HTTP_ mytest_post_conf,/      * postconfiguration * *
    
    NULL,/                              * Create main configuration/
    null,/                              * init Main configuration */
    
    NULL,/                              * Create server Configuration/
    NULL,/                              * Merge Server configuration * *
    
    ngx_http_mytest_create_loc_conf, * Create location configuration * *
    ngx_http_mytest_merge_loc_conf   /* Merge location configuration *
/};

More Wonderful content: http://www.bianceng.cnhttp://www.bianceng.cn/Servers/web/

For the sake of illustration, only create_loc_conf and merge_loc_conf are implemented here, the former in nginx.conf each http{...}, server{...}, location{...} will be called to assign an initial value to the ngx_http_mytest_conf_t, which is used to merge all the ngx_http_mytest_conf_t configuration items that are generated by create_loc_conf.

In addition, to print out the value of the Read configuration item, you need to implement ngx_http_mytest_post_conf, which is called after the configuration item is processed. In this way, the context of the module is written.

About the timing of create_loc_conf, create_srv_conf, create_main_conf calls:

Create_loc_conf is encountering every http{...}, server{...}, location{...} When

Create_srv_conf is encountering every server{...}, location{...} When

Create_main_conf only encountered http{...} When

This detail can refer to the original book.