Detailed nginx variables Method (2)

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

Another common misunderstanding about Nginx variables are considered lifetime variable container, with location configuration block binding. actually not. We look at an example involving "internal jump" in:

server {
        listen 8080;

        location /foo {
            set $a hello;
            echo_exec /bar;
        }

        location /bar {
            echo "a = [$a]";
        }
    }

Here we are in the location / foo, the use of third-party modules ngx_echo echo_exec provides configuration instructions to initiate a location / bar "internal jump." The so-called "internal jump", that is, during the processing of the request, the internal server, the process to jump from one location to another location. This is different from using "external jump" HTTP status code for 301 and 302 because the latter is in line with the jump HTTP client, and the client, the user interface can be through such browser address bar, see URL address to request a change. Jump inside and Bourne Shell (or Bash) The exec command like, it is "never to return." Another example is similar to the C language goto statement. Since it is an internal jump on the current request is being processed or the original, but the current location has changed, so that the original or a copy of Nginx variable container. Corresponds to the example, if we are requested / foo this interface, then the whole workflow is such that: the first variable $ a is assigned with the set command string hello LOCATION / foo then initiated by the internal instruction echo_exec jump, and proceeds to location / bar, and then the output value of the variable $ a. Because or the original $ a $ a, so we can expect to get hello line output. Testing confirms this:

$ curl localhost:8080/foo
a = [hello]

But if we have direct access from the client / bar interface that will get the value of $ a variable is empty, because it depends on the location / foo to $ a to initialize. We see from the above example, a request in its processing, even after a plurality of different location configuration blocks, it is still using the same set of variables Nginx copy. Here, we first relate to "internal jump" concept. It is worth mentioning that, the standard configuration instructions rewrite module ngx_rewrite fact may also initiate "internal jump", for example, the above example can be rewritten with the rewrite instruction arranged in such a form below:

server {

        listen 8080;

        location /foo {
            set $a hello;
            rewrite ^ /bar;
        }

        location /bar {
            echo "a = [$a]";
        }
    }

The effect and use echo_exec identical. Later we will be more devoted to the use of this rewrite instruction, such as 301 and 302 to initiate such "external jump." We see from the above example, the lifetime value of the variable container Nginx request is currently being processed and bound, regardless of location. We come into contact with the front Nginx variables are implicitly created through a set of instructions. These variables we generally referred to as "user-defined variables," or, more simply some "user variables." Since there are "user-defined variables," naturally the "predefined variables," provided by Nginx Nginx core and each module, or "built-in variables" (builtin variables). Nginx built-in variables most common use is to get various information about the request or response. E.g. provided by built-in variable $ URI ngx_http_core module, can be used to obtain the current request URI (decoded, and free request parameter), and is used to obtain the $ REQUEST_URI most original request URI (not decoded, and comprises request parameters). Consider the following example:

location /test {
        echo "uri = $uri";
        echo "request_uri = $request_uri";
    }

Here the sake of simplicity, even the server configuration block is omitted, and all the previous examples, we are still listening on port 8080. In this example, we and the output value of the $ uri $ request_uri to respond to the body. Here we use a different request to test the / test interfaces:

$ curl 'http://localhost:8080/test'
uri = /test
request_uri = /test

$ curl 'http://localhost:8080/test?a=3&b=4'
uri = /test
request_uri = /test?a=3&b=4

$ curl 'http://localhost:8080/test/hello%20world?a=3&b=4'
uri = /test/hello world
request_uri = /test/hello%20world?a=3&b=4

Another particularly common built-in variables is actually not a single variable, but there are an infinite number of variants of a group of variables that all variables whose names begin with arg_, we estimate and call it $ arg_XXX variable group. One example is $ arg_name, the value of this variable is the value of the current request URI parameter called name, and the original form or not decoded value. Let's look at a more complete example:

location /test {
        echo "name: $arg_name";
        echo "class: $arg_class";
    }

Then using various combinations of parameters on the command line to the request / test interfaces:

$ curl 'http://localhost:8080/test'
    name: 
    class: 

    $ curl 'http://localhost:8080/test?name=Tom&class=3'
    name: Tom
    class: 3

    $ curl 'http://localhost:8080/test?name=hello%20world&class=9'
    name: hello%20world
    class: 9

In fact, $ arg_name can not only match the name parameter, you can also match the NAME parameter, or a Name, and so on:

$ curl 'http://localhost:8080/test?NAME=Marry'
    name: Marry
    class: 

    $ curl 'http://localhost:8080/test?Name=Jimmy'
    name: Jimmy
    class:

Nginx will before matching parameter name, parameter name automatically adjusted to the original request all lowercase. If you want such a coding sequence URI parameter values% XX decoding, a third party may be used set_unescape_uri ngx_set_misc module configuration instructions:

location /test {
        set_unescape_uri $name $arg_name;
        set_unescape_uri $class $arg_class;
        echo "name: $name";
        echo "class: $class";
    }

Now we look at the results:

$ curl 'http://localhost:8080/test?name=hello%20world&class=9'
name: hello world
class: 9

Sure enough space is decoded out! From this example we can see that at the same time, this set_unescape_uri command, like set of instructions as with automatic creation function Nginx variables. Later we will be devoted to ngx_set_misc module. $ Arg_XXX like this type of variable name with endless possibilities, so they do not correspond to any storage container value. And this variable are specially treated in Nginx core, the third party can not provide Nginx modules are built-in variables so full of magic. Similar $ arg_XXX built there are many variables, such as to take the value $ cookie_XXX cookie variable group header fetch request for $ http_XXX variable groups, and means for taking a response variable $ sent_http_XXX head group. Here is not introduced one by one, interested readers can refer to the official documentation ngx_http_core module. It should be noted that many built-in variables are read-only, such as we have just introduced the $ uri and $ request_uri to assign read-only variable that should be absolutely avoided, because there will be unintended consequences, such as:

$ curl 'http://localhost:8080/test?name=hello%20world&class=9'
    name: hello world
    class: 9

This question will Nginx configuration at boot time errors reported a incredible:

[emerg] the duplicate "uri" variable in ...

If you try to rewrite some other built-in read-only variables, such as $ arg_XXX variable, in some versions of Nginx may even cause a process to crash.

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