Nginx configuration parsing

preface

Before learning one thing, please be sure to learn with questions, otherwise it is easy to get lost in a lot of things, and finally get lost in yourself. Do other things besides study is also the same, must have a strong purpose, otherwise it is easy to run out of time in a variety of miscellaneous things, spent energy and ultimately nothing.

Before we look at nginx configuration parsing, let’s take a look at how nginx configuration files are used. Here is an example nginx configuration file:

user www www; ## Default: nobody worker_processes 5; ## Default: 1 error_log logs/error.log; pid logs/nginx.pid; worker_rlimit_nofile 8192; events { worker_connections 4096; ## Default: 1024 } http { include conf/mime.types; include /etc/nginx/proxy.conf; include /etc/nginx/fastcgi.conf; index index.html index.htm index.php; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] $status ' '"$request" $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log logs/access.log main; sendfile on; tcp_nopush on; server_names_hash_bucket_size 128; # this seems to be required for some vhosts server { # php/fastcgi listen 80; server_name domain1.com www.domain1.com; access_log logs/domain1.access.log main; root html; Location ~ \.php${fastcgi_pass 127.0.0.1:1025; } } server { # simple reverse-proxy listen 80; server_name domain2.com www.domain2.com; access_log logs/domain2.access.log main; # serve static files location ~ ^/(images|javascript|js|css|flash|media|static)/ { root /var/www/virtual/big.server.com/htdocs; expires 30d; } # pass requests for dynamic content to Rails/Turbogears /zope, et al location / {proxy_pass http://127.0.0.1:8080; }} upstream big_server_com {server 127.0.3:8000 weight=5; Server 127.0.0.3:8001 weight = 5; Server 192.168.0.1:8000; Server 192.168.0.1:8001; } server { # simple load balancing listen 80; server_name big.server.com; access_log logs/big.server.access.log main; location / { proxy_pass http://big_server_com; }}}Copy the code

Without knowing anything about nginx configuration, we can categorize the above configuration according to our own understanding and see what kinds of configurations there are.

  • Partition by location where the configuration appears
  1. Configuration at the outermost level

Includes user, worker_processes, etc., and does not belong to any {} configuration block

user       www www;  ## Default: nobody
worker_processes  5;  ## Default: 1
error_log  logs/error.log;
pid        logs/nginx.pid;
worker_rlimit_nofile 8192;
Copy the code
  1. Configuration within a block

This includes configuration within HTTP, Events, and other blocks

events {
  worker_connections  4096;  ## Default: 1024
}
Copy the code
  • According to the number of parameters
  1. Configuration with one parameter

Includes worker_PROCESSES, etc., with a single parameter

worker_processes  5;  ## Default: 1
Copy the code
  1. Configuration with multiple parameters

Multiple parameters exist, including index

index    index.html index.htm index.php;
Copy the code
  • According to the parameter type
  1. The parameter is a common numeric configuration

Including worker_PROCESSES and so on, the argument is a numeric value

worker_processes  5;
Copy the code
  1. The parameter is a common string configuration

Including server_name, the parameter is a normal string

server_name     big.server.com;
Copy the code
  1. The parameter is a configuration with a unit value

This includes things like Expires, with units in the parameters

expires 30d;
Copy the code
  1. The parameter is a configuration with a special operation string

Including server and other parameters in the assignment and other operations

Server 127.0.0.3:8000 weight = 5;Copy the code
  1. Parameters support multiple types of configurations

Parameters such as server can take various forms

Server {} server 127.0.0.3:8000 weight=5;Copy the code

In the process of classification and analysis of the configuration above, the problem naturally accumulated, if there is no doubt after reading, or it is very clear, or it is not seriously look. I personally raised the following questions in the process of analysis:

  1. How is the location of the configuration item determined? Why are some configuration items outside the file and others inside a configuration block?
  2. Each module has its own configuration items. How does Nginx organize them together?
  3. Each module defines its own configuration items. How does Nginx make each module handle its own configuration items separately?
  4. If I have a custom module with its own configuration items, how should I integrate my module configuration parsing into Nginx?
  5. Each configuration item has one parameter, several parameters, and multiple types coexist. How does nginx handle these configuration item parameters?
  6. Nginx defines configuration items that define configuration blocks, such ashttp,eventHow did you handle it?
  7. How does include implement importing other file configurations?

Let’s begin our analysis of nginx source code with the above questions in mind.

Configuration parsing series:

Learning with Problems –Nginx Configuration Parsing (Introduction)

Nginx configuration With Problems to Learn