Detailed methods nginx variables (6)

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

When Nginx built-in variables used in the context of "sub-request" in its behavior will become somewhat subtle. In front of the (three), we already know that a lot of built-in variables are not simple "storage container values", they generally through registration "access processing program" to behave different, and they even have a store of value container, only for cache "access processing program" calculation. We discussed earlier $ args variable is the parameter string to return the URL of the current request through its "take handler." Because this request may also be a "sub-request", it reads the $ args "sub-request" in which "get handler" will naturally return to the parameter string "sub-request". Let's look at an example of this:

location /main {
        echo "main args: $args";
        echo_location /sub "a=1&b=2";
    }

    location /sub {
        echo "sub args: $args";
    }

Here in / main interface, the first output current value of the variable $ args echo request with the instruction, and then instruction is initiated then echo_location sub-request / sub. It is worth noting that, apart is specified by the first parameter in the statement echo_location outside "sub-request" in the URI, the second parameter is also provided to specify the "sub-request" in the URL parameter string (i.e., a = 1 & b = 2). Finally, we define / sub interfaces, value $ args in which output a bit. Request / main result interfaces are as follows: $ curl 'http: // localhost:? 8080 / main c = 3' main args: c = 3 sub args: a = 1 & b = 2 Obviously, when $ args used in a "master request" URL parameter string / time, simply "master request" main outputted, c = 3; and when used in a "sub-request" / time sub, the output of the parameter string "sub-request", a = 1 & b = 2. This behavior is in line with our intuition. $ Args and similar, used in the built-in variable $ URI "child Request", its "get handler" will correctly return the current "sub-request" parsed URI:

location /main {
        echo "main uri: $uri";
        echo_location /sub;
    }

    location /sub {
        echo "sub uri: $uri";
    }

Results Request / main is

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

This is still what we expect. Unfortunately, not all of the built-in variables are applied to the current request. Act only on a few built-in variables "master request", such as provided by the standard built-in variable module ngx_http_core $ request_method. REQUEST_METHOD variable $ when read, always get "master request" request methods, such as GET, POST of class. Let's test:

location /main {
        echo "main method: $request_method";
        echo_location /sub;
    }

    location /sub {
        echo "sub method: $request_method";
    }

In this example, / main and / sub interface on each output value of $ REQUEST_METHOD. At the same time, we launched a to / sub GET interface "sub-request" instruction in the use of echo_location / main interfaces inside. We now use the curl command line tool to initiate a / POST requests main interface:

$ curl --data hello 'http://localhost:8080/main'
    main method: POST
    sub method: POST

Here we use curl program --data option to specify hello to our request as volume data, while --data option automatically make requests sent using the POST request method. The test results proved that our previous predictions, $ request_method variable even in GET "sub-request" / sub used, the resulting value is still the request method "main request" / main's, POST. Some readers may feel that we are here at some hasty conclusions, because the case is the first in the "main request" in reading (and output) $ request_method variable, then only made "sub-request", these readers may think this does not rule out a request to enter the sub $ request_method before the first has been read to the buffer live value, thus affecting subsequent sub output request. However, this concern is unnecessary, as we in the front (V) is also mentioned in particular, the value of the cache depends container variable is bound with the current request, initiated by the ngx_echo module "sub-request" variables are shared between the disable request Sons, so in the embodiment, even if the built-in variable $ REQUEST_METHOD value actually used as a buffer vessel (in fact it is not), it can not affect the / sub sub-request. In order to eliminate this part of the reader's concerns, we might as well just slightly modify that example, the time / main interface output $ request_method variable deferred to the "sub-request" is finished after:

location /main {
        echo_location /sub;
        echo "main method: $request_method";
    }

    location /sub {
        echo "sub method: $request_method";
    }

Let us re-test:

$ curl --data hello 'http://localhost:8080/main'
    sub method: POST
    main method: POST

It can be seen again POST method request / main result is consistent with that interfaces the original example except that the output order of the parent-child requests reversed (because we exchanged / main configuration interface that two output instruction in the present embodiment the the order). Thus, we are not able to obtain a standard variable $ request_method request method "sub-request". In order to achieve our initial goal, we need to resort to third-party modules ngx_echo built-in variables provided $ echo_request_method:

location /main {
        echo "main method: $echo_request_method";
        echo_location /sub;
    }

    location /sub {
        echo "sub method: $echo_request_method";
    }

At this time, the output finally we want the:

$ curl --data hello 'http://localhost:8080/main'
    main method: POST
    sub method: GET

We see that father and son were requested output of their different request method, POST and GET. Similarly $ request_method, built-in variable $ request_uri generally returned is not parsed URL "main request", after "sub-request" Nginx is initiated inside, there is no so-called "unresolved" in its original form. If, as earlier feared that some readers, built-in value of the variable buffer between father and son shared variable request played a role, this is disastrous. In front of us (five) have been seen ngx_auth_request module launched the "sub-request" is its "parent request" share a set of variables. Here is one such terrible examples:

map $uri $tag {
        default     0;
        /main       1;
        /sub        2;
    }

    server {
        listen 8080;

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

        location /sub {
            echo "sub tag: $tag";
        }
    }

Here we use returning to the map command to map the built-in variable $ user variable $ uri to the tag. When the value of $ URI / main, $ tag value 1 is given, when the value of $ URI / sub, 2 is given $ tag value, otherwise Ode 0. Next, we / main interface with the first ngx_auth_request auth_request to the command module initiates / sub interface sub-request, and then outputs the value of the variable $ tag. In / sub interface, we direct the output variable $ tag. Guess what, if we access interface / main, will be what kind of output it?

$ curl 'http://localhost:8080/main'
    main tag: 2

Huh? We are not clear to / main value of 1 mapped to it? Why is the actual output / outcome mapping sub 2 do? In fact, the reason is very simple, because our variable $ tag is first read in the "sub-request" / sub in, so there calculated the value 2 (since $ uri where the value / sub, according to the map and mapping rules, $ it tag value 2), was $ tag from the container to the buffer value lived. Result auth_request initiated "sub-request" is a set of shared variables and the "parent request", then when the "parent request" $ tag values ​​of the output variables is performed Nginx flows back, it simply returns the cached Nginx live 2 a. This result is really so unexpected. From this example we see once again, request variables shared between father and son, it is not a good idea.

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