Detailed methods nginx variables (5)

Why 80% of the code can not do farming architect? >>>  

In front of the (two), we have learned the value of variable life of the container is requesting the bond, but I was shunned formal definition of "request". It should have been here by default "request" all refer to the HTTP request initiated by the client. In fact, there are two types of "request", called "main request" (main request), while the other is called "sub-request" (subrequest) in Nginx world. Let's introduce them. The so-called "main request" is initiated by the HTTP client from Nginx external requests. All our previous examples relate only to see "master request", examples of the "internal jump" include (II) and two using echo_exec rewrite instruction is initiated. The "sub-request" Cascaded Request is being processed by the inside Nginx Nginx initiated. "Sub-request" HTTP request like in appearance, but to achieve it, and HTTP protocol network traffic as well as a little nothing to do. It is an internal call to Nginx abstract, is intended to facilitate the user to "master request" task into a plurality of smaller particle size "internal request", concurrently or serially a plurality of access interfaces location, then the location of these Interface working together to complete the "main request." Of course, the concept of "sub-request" is relative, any "sub-request" can also be re-initiate more "sub-sub-request", and even play a recursive call (ie calls itself). When a request to initiate a "sub-request" when, in accordance with the terms of Nginx, the former is referred to the latter's habit "Parent Request" (parent request). It is worth mentioning that, in fact, there are Apache server is also the concept of "sub-request", so the reader from the Apache world this should not be unfamiliar. Here we look at an example of "sub-request" in:

location /main {
        echo_location /foo;
        echo_location /bar;
    }

    location /foo {
        echo foo;
    }

    location /bar {
        echo bar;
    }

Here in location / main in, respectively, to initiate / foo and / bar GET these two types of interfaces of "sub-request" by a third party ngx_echo echo_location command module. Echo_location initiated by the "sub-request", which is performed in the order written configured serial processing, i.e., only when the / foo request is processed only after the next process / bar requests. The two "sub-request" in the output sequence will be executed in stitching together, as / main final output interface:

$ curl 'http://localhost:8080/main'
    foo
    bar

We see that "sub-request" communication is carried out within the same virtual host, so the core of Nginx in the realization of "sub-request", it is only the number of C function calls, it does not involve any network or UNIX sets Sockets (Socket) communication. We can see that "sub-request," the efficiency is very high. Returning to the discussion of the previous Nginx variable value of the lifetime of the vessel, we can still say, their life span is associated with the current request. Independent copy of each request all containers of variable values, but the current request either a "main request" can also be "sub-request." Even between the father and son request, the same variables are generally do not interfere with each other. Let's look through a small experiment to prove this statement:

location /main {
        set $var main;
        echo_location /foo;
        echo_location /bar;
        echo "main: $var";
    }

    location /foo {
        set $var foo;
        echo "foo: $var";
    }

    location /bar {
        set $var bar;
        echo "bar: $var";
    }

In this example, we are in the / main, / foo and / bar location three blocks configured as a variable of the same name, $ var, are set to be different values ​​and outputs. In particular, we / main interface, deliberately calling over / foo and / bar after the two "sub-request", then the output value of its own $ var variable. Request / result main interface is such that:

$ curl 'http://localhost:8080/main'
    foo: foo
    bar: bar
    main: main

Obviously, / foo and / bar two "sub-request" in the process of modifying the variable $ var each have made did not affect the "main request" / main. So this confirms the success of the "main request" and the various "sub-request" has a different copy of the variable $ var the value of container. Unfortunately, some of Nginx module launched the "sub-request" is automatically shared variable value of its container "parent request", such as third-party modules ngx_auth_request Here is an example:

location /main {
        set $var main;
        auth_request /sub;
        echo "main: $var";
    }

    location /sub {
        set $var sub;
        echo "sub: $var";
    }

Here, we first initial value for the variable in the $ var / main interface main, and then use the configuration module provides instructions ngx_auth_request auth_request, to initiate a / sub interface "sub-request", the final output command using the echo of the value of $ var. While we deliberately put the value of the variable $ var rewritten in sub / sub interface to access / main result interfaces are as follows:

$ curl 'http://localhost:8080/main'
    main: sub

We see, / sub interface to modify $ var variable values ​​affected the main request / main. So ngx_auth_request module launched the "sub-request" is indeed its "parent request" a set of shared values ​​Nginx variable container. For the example above, I believe readers will ask: 'Why?' Sub-request '/ output sub does not appear in the final output in it. "The answer is simple, it is because auth_request command will automatically ignore the" sub-request "response body , but only check "sub-request" in the response status code. When the status code is 2XX time, auth_request instruction will ignore the "sub-request" and let Nginx continue processing the current request, or it will immediately interrupt the execution of the current (main) request and returns the appropriate error page. In our example, / sub "sub-request" instruction except echo made some output, implicitly returned status code 200 indicating the normal. Modules such as ngx_auth_request father and son shared a request Nginx variable behavior, although you can make two-way data transfer between father and son becomes extremely easy request, but sufficient for complex configurations, but also often lead to a lot of difficult to debug strange bug. Because users often do not know the value of a variable Nginx "parent request", in fact, has been accidentally modify it in a "sub-request". Because like sharing a result of bad "side effects" so many third-party modules include ngx_echo, ngx_lua, and ngx_srcache have chosen variables, including shared between father and son is disabled request.

Reproduced in: https: //my.oschina.net/766/blog/211544