Nginx 变量漫谈(六)

Nginx 内建变量用在“子请求”的上下文中时,其行为也会变得有些微妙。

前面在 (三) 中我们已经知道,许多内建变量都不是简单的“存放值的容器”,它们一般会通过注册“存取处理程序”来表现得与众不同,而它们即使有存放值的容器,也只是用于缓存“存取处理程序”的计算结果。我们之前讨论过的 $args 变量正是通过它的“取处理程序”来返回当前请求的 URL 参数串。因为当前请求也可以是“子请求”,所以在“子请求”中读取 $args,其“取处理程序”会很自然地返回当前“子请求”的参数串。我们来看这样的一个例子:

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

这里在 /main 接口中,先用 echo 指令输出当前请求的 $args 变量的值,接着再用 echo_location 指令发起子请求 /sub. 这里值得注意的是,我们在 echo_location 语句中除了通过第一个参数指定“子请求”的 URI 之外,还提供了第二个参数,用以指定该“子请求”的 URL 参数串(即 a=1&b=2)。最后我们定义了 /sub 接口,在里面输出了一下 $args 的值。请求 /main 接口的结果如下:

    $ curl ‘http://localhost:8080/main?c=3‘    main args: c=3    sub args: a=1&b=2

显然,当 $args 用在“主请求” /main 中时,输出的就是“主请求”的 URL 参数串,c=3;而当用在“子请求” /sub 中时,输出的则是“子请求”的参数串,a=1&b=2。这种行为正符合我们的直觉。

与 $args 类似,内建变量 $uri 用在“子请求”中时,其“取处理程序”也会正确返回当前“子请求”解析过的 URI:

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

请求 /main 的结果是

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

这依然是我们所期望的。

但不幸的是,并非所有的内建变量都作用于当前请求。少数内建变量只作用于“主请求”,比如由标准模块ngx_http_core 提供的内建变量 $request_method.

变量 $request_method 在读取时,总是会得到“主请求”的请求方法,比如 GETPOST 之类。我们来测试一下:

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

在这个例子里,/main 和 /sub 接口都会分别输出 $request_method 的值。同时,我们在 /main 接口里利用echo_location 指令发起一个到 /sub 接口的 GET “子请求”。我们现在利用 curl 命令行工具来发起一个到/main 接口的 POST 请求:

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

这里我们利用 curl 程序的 --data 选项,指定 hello 作为我们的请求体数据,同时 --data 选项会自动让发送的请求使用 POST 请求方法。测试结果证明了我们先前的预言,$request_method 变量即使在 GET “子请求” /sub 中使用,得到的值依然是“主请求” /main 的请求方法,POST.

有的读者可能觉得我们在这里下的结论有些草率,因为上例是先在“主请求”里读取(并输出)$request_method 变量,然后才发“子请求”的,所以这些读者可能认为这并不能排除 $request_method在进入子请求之前就已经把第一次读到的值给缓存住,从而影响到后续子请求中的输出结果。不过,这样的顾虑是多余的,因为我们前面在 (五) 中也特别提到过,缓存所依赖的变量的值容器,是与当前请求绑定的,而由ngx_echo 模块发起的“子请求”都禁用了父子请求之间的变量共享,所以在上例中,$request_method 内建变量即使真的使用了值容器作为缓存(事实上它也没有),它也不可能影响到 /sub 子请求。

为了进一步消除这部分读者的疑虑,我们不妨稍微修改一下刚才那个例子,将 /main 接口输出$request_method 变量的时间推迟到“子请求”执行完毕之后:

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

让我们重新测试一下:

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

可以看到,再次以 POST 方法请求 /main 接口的结果与原先那个例子完全一致,除了父子请求的输出顺序颠倒了过来(因为我们在本例中交换了 /main 接口中那两条输出配置指令的先后次序)。

由此可见,我们并不能通过标准的 $request_method 变量取得“子请求”的请求方法。为了达到我们最初的目的,我们需要求助于第三方模块 ngx_echo 提供的内建变量 $echo_request_method

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

此时的输出终于是我们想要的了:

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

我们看到,父子请求分别输出了它们各自不同的请求方法,POST 和 GET.

类似 $request_method,内建变量 $request_uri 一般也返回的是“主请求”未经解析过的 URL,毕竟“子请求”都是在 Nginx 内部发起的,并不存在所谓的“未解析的”原始形式。

如果真如前面那部分读者所担心的,内建变量的值缓存在共享变量的父子请求之间起了作用,这无疑是灾难性的。我们前面在 (五) 中已经看到 ngx_auth_request 模块发起的“子请求”是与其“父请求”共享一套变量的。下面是一个这样的可怕例子:

    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";        }    }

这里我们使用久违了的 map 指令来把内建变量 $uri 的值映射到用户变量 $tag 上。当 $uri 的值为 /main时,则赋予 $tag 值 1,当 $uri 取值 /sub 时,则赋予 $tag 值 2,其他情况都赋 0. 接着,我们在 /main接口中先用 ngx_auth_request 模块的 auth_request 指令发起到 /sub 接口的子请求,然后再输出变量 $tag的值。而在 /sub 接口中,我们直接输出变量 $tag. 猜猜看,如果我们访问接口 /main,将会得到什么样的输出呢?

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

咦?我们不是分明把 /main 这个值映射到 1 上的么?为什么实际输出的是 /sub 映射的结果 2 呢?

其实道理很简单,因为我们的 $tag 变量在“子请求” /sub 中首先被读取,于是在那里计算出了值 2(因为 $uri 在那里取值 /sub,而根据 map 映射规则,$tag 应当取值 2),从此就被 $tag 的值容器给缓存住了。而 auth_request 发起的“子请求”又是与“父请求”共享一套变量的,于是当 Nginx 的执行流回到“父请求”输出 $tag 变量的值时,Nginx 就直接返回缓存住的结果 2 了。这样的结果确实太意外了。

从这个例子我们再次看到,父子请求间的变量共享,实在不是一个好主意。

(未完待续)

时间: 2024-10-07 09:24:21

Nginx 变量漫谈(六)的相关文章

Nginx 变量漫谈(一)

Nginx 的配置文件使用的就是一门微型的编程语言,许多真实世界里的 Nginx 配置文件其实就是一个一个的小程序.当然,是不是“图灵完全的”暂且不论,至少据我观察,它在设计上受 Perl 和 Bourne Shell 这两种语言的影响很大.在这一点上,相比 Apache 和 Lighttpd 等其他 Web 服务器的配置记法,不能不说算是 Nginx 的一大特色了.既然是编程语言,一般也就少不了“变量”这种东西(当然,Haskell 这样奇怪的函数式语言除外了). 熟悉 Perl.Bourne

Nginx 变量漫谈(五)

前面在 (二) 中我们已经了解到变量值容器的生命期是与请求绑定的,但是我当时有意避开了“请求”的正式定义.大家应当一直默认这里的“请求”都是指客户端发起的 HTTP 请求.其实在 Nginx 世界里有两种类型的“请求”,一种叫做“主请求”(main request),而另一种则叫做“子请求”(subrequest).我们先来介绍一下它们. 所谓“主请求”,就是由 HTTP 客户端从 Nginx 外部发起的请求.我们前面见到的所有例子都只涉及到“主请求”,包括 (二) 中那两个使用 echo_ex

Nginx 变量漫谈(七)

在 (一) 中我们提到过,Nginx 变量的值只有一种类型,那就是字符串,但是变量也有可能压根就不存在有意义的值.没有值的变量也有两种特殊的值:一种是“不合法”(invalid),另一种是“没找到”(not found). 举例说来,当 Nginx 用户变量 $foo 创建了却未被赋值时,$foo 的值便是“不合法”:而如果当前请求的 URL 参数串中并没有提及 XXX 这个参数,则 $arg_XXX 内建变量的值便是“没找到”. 无论是“不合法”也好,还是“没找到”也罢,这两种 Nginx 变

Nginx 变量漫谈(二)

关于 Nginx 变量的另一个常见误区是认为变量容器的生命期,是与 location 配置块绑定的.其实不然.我们来看一个涉及“内部跳转”的例子:     server {        listen 8080;         location /foo {            set $a hello;            echo_exec /bar;        }         location /bar {            echo "a = [$a]";  

nginx变量(日志)

nginx变量(日志) HTTP请求变量 - arg_PARAMETER.http_HEADER.sent_http_HEADER 它是指http请求中的变量,举例: 修改/etc/nginx/nginx.conf 访问页面 内置变量 - ngnix内置的 http://nginx.org/en/docs/http/ngx_http_log_module.html#log_format

Nginx详解六:Nginx基础篇之Nginx日志

1.Nginx日志类型 error.log:记录Nginx处理http请求的错误的状态,以及Nginx服务本身服务运行的错误的状态 access_log:记录通过Nginx的http请求的访问状态,用于对每一次访问的请求和客户进行的交互以及对行为的一些分析 实现方法:log_format error_log: access_log: 查看一下 2.Nginx变量 HTTP请求变量 - arg_PARAMETER.http_HEADER.sent_http_HEADER 内置变量 - Nginx内

Nginx使用教程(六):使用Nginx缓存之FastCGI缓存

启用FastCGI缓存 <br\>编辑必须启用缓存的虚拟主机配置文件. nano /etc/nginx/sites-enabled/vhost 将以下行添加到server{}指令之外的文件顶部: fastcgi_cache_path /etc/nginx/cache levels=1:2 keys_zone=MYAPP:100m inactive=60m; fastcgi_cache_key "$scheme$request_method$host$request_uri"

nginx变量

$arg_PARAMETER                 功能:如果在请求中设置了查询字符串,那么这个变量包含在查询字符串是GET请求PARAMETER中的值. $args                                        功能:该变量的值是GET请求在请求行中的参数. $binary_remote_addr          功能:二进制格式的客户端地址 $body_bytes_sent                 功能:响应体的大小,即使发生了中断或者是放

Nginx学习笔记六Nginx的模块开发

1.Nginx配置文件主要组成:main(全局配置)这部分的指令将影响其他所有部分.server(虚拟主机配置)这部分指令主要用于指定虚拟主机域名,IP和端口.upstream(主要为反向代理,负载均衡相关配置)这部分指令用于设置反向代理及后端服务 器的负载均衡.location(目录匹配配置)这部分指令用于匹配网页位置(例如,根目录"/","/images",等 等). location部分会继承server部分的指令,而server部分会继承main部分的指令.