This is the 23rd day of my participation in Gwen Challenge

background

This is the fifth in a series of notes on customizing Nginx plugins.

Custom development of Nginx plug-ins

Nginx development common modules

There are three common types of modules that require custom development: Handler,filter, and load-balancer

A Handler module is a module that accepts requests from a client and generates output. An upstream module is also called a Handler module, except that the content is retrieved from the backend server rather than generated locally

The filter module

After the content generation stage is completed, the generated output will be passed to the Filter module for processing. The filter module is also related to location. All the filter modules are organized into a chain, and the output will pass through all the filters in turn until the return value of one filter module indicates that processing has been completed

A few common filter modules:

  • server-side includes
  • XSLT filtering
  • Image scaling and stuff like that
  • Gzip compression

There are several filter modules in particular, described in order of invocation:

  • Write: Writes the output to the client, actually to the socket corresponding to the connection
  • As for the subrequest, the filter is responsible for it
  • Copy: Copy some BUFs (files or memory) that need to be copied and give them to the rest of the Body filter

Location and handler modules

Content can be configured in the configuration file using the Location directive Handler module. When Nginx starts, each handler module has a chance to associate itself with the corresponding location. If multiple handler modules are associated with the same location, then only one handler module really works Avoid this situation

Handler to deal with

The handler module typically processes results in one of three situations:

  • Handle a successful
  • Processing failure (error occurred while processing)
  • Refuse to deal with

In the case of rejection processing for this location is handled by the default handler module, for example, ngx_HTTP_STATIC_MODUL if a handler module associated with this location rejects a request for a static file The e module is a typical handler module

Module configuration structure

  • Each module provides some configuration instructions. Users control the behavior of the module through configuration. Nginx stores information by defining the configuration structure of the module
  • Nginx configuration information is divided into several scopes (sometimes called contexts), namely main,server, and location. Each module provides configuration instructions that need to be stored in three different data structures
  • The configuration data structure of a module is defined on demand, in whichever scope it needs to be used in, so not all modules define three scoped data structures
  • In the development process of the module, it is best to use Nginx original naming habits, naming habits are ngx_http__ module configuration data structure (the main | the SRV | loc) _conf_t
typedef struct {
    ngx_str_t hello_string;
    ngx_int_t hello_counter;
} ngx_http_hello_loc_conf_t;
Copy the code

Ngx_command_t structure

The ngx_command_t structure is defined in SRC /core/ngx_conf_file.h

struct ngx_command_s {
    ngx_str_t             name;
    ngx_uint_t            type;
    char               *(*set)(ngx_conf_t *cf, ngx_command_t *cmd, void *conf);
    ngx_uint_t            conf;
    ngx_uint_t            offset;
    void                 *post;
};
Copy the code

Name: indicates the name of the configuration command

Nginx provides a number of predefined property values (some macro definitions) that can be combined by logic or operators to form a detailed description of the configuration directive. These predefined property values include:

NGX_CONF_NOARGS: the configuration directive does not accept any parameters. NGX_CONF_TAKE1: The configuration directive accepts one parameter. NGX_CONF_TAKE2: the configuration directive accepts two parameters. The configuration command accepts three parameters. NGX_CONF_TAKE4: the configuration command accepts four parameters. NGX_CONF_TAKE5: the configuration command accepts five parametersCopy the code

Can combine multiple attributes, such as an instruction that is can not fill in the parameter, also can accept one or two parameters, then NGX_CONF_NOARGS | NGX_CONF_TAKE1 | NGX_CONF_TAKE2

Nginx provides definitions to simplify attribute composition

NGX_CONF_TAKE12: configuration command accepts one or two parameters NGX_CONF_TAKE13: configuration command accepts one or three parameters NGX_CONF_TAKE23: configuration command accepts two or three parameters NGX_CONF_TAKE123: NGX_CONF_TAKE1234: Configuration directive accepts one or two or three parameters NGX_CONF_1MORE: configuration directive accepts at least one parameter NGX_CONF_2MORE: The configuration instruction accepts at least two parameters NGX_CONF_MULTI: NGX_CONF_BLOCK: The value accepted by a configuration directive is a block of configuration information enclosed in curly braces, which can contain many configuration directives. For example, the common server directive is the NGX_CONF_FLAG of this property: NGX_CONF_ANY: Any parameter values that can be accepted by the configuration directive, one or more, either "on" or "off", or a configuration blockCopy the code

The number of parameters in Nginx configuration instructions cannot exceed NGX_CONF_MAX_ARGS. This value is defined as 8, i.e., no more than 8 parameter values

Configure the properties of where instructions can appear:

NGX_DIRECT_CONF: can appear in the outermost configuration file, such as the provided configuration commands daemon,master_process, etc. HTTP, mail, events, error_log NGX_ANY_CONF: This configuration directive can appear at any configuration levelCopy the code

Most modules deal with HTTP-related issues, namely NGX_HTTP_MODULE. For this type of module, the configuration can be divided into direct HTTP and other locations:

NGX_HTTP_SRV_CONF: can be used in the HTTP server configuration directive. Ups_conf: NGX_HTTP_UPS_CONF: NGX_HTTP_UPS_CONF: NGX_HTTP_UPS_CONF: NGX_HTTP_UPS_CONF: NGX_HTTP_UPS_CONF: NGX_HTTP_UPS_CONF: NGX_HTTP_UPS_CONF: NGX_HTTP_UPS_CONF: NGX_HTTP_UPS_CONF: NGX_HTTP_UPS_CONF: NGX_HTTP_LMT_CONF: NGX_HTTP_LIF_CONF: NGX_HTTP_LMT_CONF: NGX_HTTP_LIF_CONF: It can appear in the block of the IF statement in the LOCATION configuration directive inside the HTTP server blockCopy the code

Nginx provides some standard parameter reading functions by default, which can be directly assigned to the set field. The following are the set type functions implemented:

Ngx_conf_set_flag_slot: reads parameters of type NGX_CONF_FLAG. Ngx_conf_set_str_slot: reads parameters of type string. Ngx_conf_set_str_array_slot: Ngx_conf_set_keyval_slot: ngx_CONF_set_num_slot: ngx_conf_set_num_slot Ngx_conf_set_size_slot: Read arguments to size_t, that is, unsigned numbers ngx_conf_set_off_slot: Read off_t parameter ngx_conf_set_msec_slot: read millisecond parameter ngx_CONF_set_sec_slot: read second parameter ngx_conf_set_bufs_slot: read second parameter ngx_conf_set_bufs_slot: The values of two parameters are the number of BUFs and the size of buFs, for example, output_buffers 1 128K. Ngx_conf_set_enum_slot: Reads parameters of enumeration type and converts them to integers. Ngx_uint_t ngX_CONF_set_bitMASk_slot: Read the values of parameters and store the values of those parameters as bits, such as the DAV_methods directive of the HttpDavModule moduleCopy the code