Nginx 变量漫谈(二)

关于 Nginx 变量的另一个常见误区是认为变量容器的生命期,是与 location 配置块绑定的。其实不然。我们来看一个涉及“内部跳转”的例子:

    server {        listen 8080;         location /foo {            set $a hello;            echo_exec /bar;        }         location /bar {            echo "a = [$a]";        }    }

这里我们在 location /foo 中,使用第三方模块 ngx_echo 提供的 echo_exec 配置指令,发起到 location /bar 的“内部跳转”。所谓“内部跳转”,就是在处理请求的过程中,于服务器内部,从一个 location 跳转到另一个 location 的过程。这不同于利用 HTTP 状态码 301 和 302 所进行的“外部跳转”,因为后者是由 HTTP 客户端配合进行跳转的,而且在客户端,用户可以通过浏览器地址栏这样的界面,看到请求的 URL 地址发生了变化。内部跳转和 Bourne Shell(或 Bash)中的 exec 命令很像,都是“有去无回”。另一个相近的例子是 C 语言中的 goto 语句。

既然是内部跳转,当前正在处理的请求就还是原来那个,只是当前的 location 发生了变化,所以还是原来的那一套 Nginx 变量的容器副本。对应到上例,如果我们请求的是 /foo 这个接口,那么整个工作流程是这样的:先在 location /foo 中通过 set 指令将 $a 变量的值赋为字符串 hello,然后通过 echo_exec 指令发起内部跳转,又进入到 location /bar 中,再输出 $a 变量的值。因为 $a 还是原来的 $a,所以我们可以期望得到 hello 这行输出。测试证实了这一点:

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

但如果我们从客户端直接访问 /bar 接口,就会得到空的 $a 变量的值,因为它依赖于 location /foo 来对 $a进行初始化。

从上面这个例子我们看到,一个请求在其处理过程中,即使经历多个不同的 location 配置块,它使用的还是同一套 Nginx 变量的副本。这里,我们也首次涉及到了“内部跳转”这个概念。值得一提的是,标准ngx_rewrite 模块的 rewrite 配置指令其实也可以发起“内部跳转”,例如上面那个例子用 rewrite 配置指令可以改写成下面这样的形式:

    server {        listen 8080;         location /foo {            set $a hello;            rewrite ^ /bar;        }         location /bar {            echo "a = [$a]";        }    }

其效果和使用 echo_exec 是完全相同的。后面我们还会专门介绍这个 rewrite 指令的更多用法,比如发起 301和 302 这样的“外部跳转”。

从上面这个例子我们看到,Nginx 变量值容器的生命期是与当前正在处理的请求绑定的,而与 location 无关。

前面我们接触到的都是通过 set 指令隐式创建的 Nginx 变量。这些变量我们一般称为“用户自定义变量”,或者更简单一些,“用户变量”。既然有“用户自定义变量”,自然也就有由 Nginx 核心和各个 Nginx 模块提供的“预定义变量”,或者说“内建变量”(builtin variables)。

Nginx 内建变量最常见的用途就是获取关于请求或响应的各种信息。例如由 ngx_http_core 模块提供的内建变量 $uri,可以用来获取当前请求的 URI(经过解码,并且不含请求参数),而 $request_uri 则用来获取请求最原始的 URI (未经解码,并且包含请求参数)。请看下面这个例子:

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

这里为了简单起见,连 server 配置块也省略了,和前面所有示例一样,我们监听的依然是 8080 端口。在这个例子里,我们把 $uri 和 $request_uri 的值输出到响应体中去。下面我们用不同的请求来测试一下这个 /test接口:

    $ 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

另一个特别常用的内建变量其实并不是单独一个变量,而是有无限多变种的一群变量,即名字以 arg_ 开头的所有变量,我们估且称之为 $arg_XXX 变量群。一个例子是 $arg_name,这个变量的值是当前请求名为 name 的 URI 参数的值,而且还是未解码的原始形式的值。我们来看一个比较完整的示例:

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

然后在命令行上使用各种参数组合去请求这个 /test 接口:

    $ 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

其实 $arg_name 不仅可以匹配 name 参数,也可以匹配 NAME 参数,抑或是 Name,等等:

    $ curl ‘http://localhost:8080/test?NAME=Marry‘    name: Marry    class:      $ curl ‘http://localhost:8080/test?Name=Jimmy‘    name: Jimmy    class:

Nginx 会在匹配参数名之前,自动把原始请求中的参数名调整为全部小写的形式。

如果你想对 URI 参数值中的 %XX 这样的编码序列进行解码,可以使用第三方 ngx_set_misc 模块提供的set_unescape_uri 配置指令:

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

现在我们再看一下效果:

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

空格果然被解码出来了!

从这个例子我们同时可以看到,这个 set_unescape_uri 指令也像 set 指令那样,拥有自动创建 Nginx 变量的功能。后面我们还会专门介绍到 ngx_set_misc 模块。

像 $arg_XXX 这种类型的变量拥有无穷无尽种可能的名字,所以它们并不对应任何存放值的容器。而且这种变量在 Nginx 核心中是经过特别处理的,第三方 Nginx 模块是不能提供这样充满魔法的内建变量的。

类似 $arg_XXX 的内建变量还有不少,比如用来取 cookie 值的 $cookie_XXX 变量群,用来取请求头的$http_XXX 变量群,以及用来取响应头的 $sent_http_XXX 变量群。这里就不一一介绍了,感兴趣的读者可以参考 ngx_http_core 模块的官方文档。

需要指出的是,许多内建变量都是只读的,比如我们刚才介绍的 $uri 和 $request_uri. 对只读变量进行赋值是应当绝对避免的,因为会有意想不到的后果,比如:

    ? location /bad {    ?     set $uri /blah;    ?     echo $uri;    ? }

这个有问题的配置会让 Nginx 在启动的时候报出一条令人匪夷所思的错误:

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

如果你尝试改写另外一些只读的内建变量,比如 $arg_XXX 变量,在某些 Nginx 的版本中甚至可能导致进程崩溃。

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

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

Nginx 变量漫谈(五)

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

Nginx 变量漫谈(一)

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

Nginx 变量漫谈(七)

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

Nginx 变量漫谈(六)

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

转载:Centos7 从零编译Nginx+PHP+MySql 二

序言 这次玩次狠得.除了编译器使用yum安装,其他全部手动编译.哼~ 看似就Nginx.PHP.MySql三个东东,但是它们太尼玛依赖别人了. 没办法,想用它们就得老老实实给它们提供想要的东西. 首先的一些模块依赖一些lib库, 如果你是懒人,就顺着下面的命令分别输入就行了.然后直接看配置篇.(不过这样安装的可不是最新版本的哟) 目录 一.Centos7 从零编译Nginx+PHP+MySql 二.Centos7 从零配置Nginx+PHP+MySql 三.Centos7 从零编译配置Memca

ZabbixAPI+django+nginx简单的二次开发实例(三)

接上一篇博文 ZabbixAPI+django+nginx简单的二次开发实例(二) 步骤三,站点架构部分 本部分用到的软件 1,Nginx:接受访问请求,应答静态页面,转发动态请求至uwsgi 2,uwsgi:应答动态请求 3,Django:处理后台数据 4,supervisor:管理进程 首先安装Nginx yum install epel-release yum install python-devel nginx 修改配置文件 vim /etc/ngnix/ngnix.conf user

ZabbixAPI+django+nginx简单的二次开发实例(五)

接上一篇博文 ZabbixAPI+django+nginx简单的二次开发实例(四) 步骤五,图形展示 写一个RRDtool图形展示的脚本,由于要和view.py联动,我放在了appname的文件夹下 cd /API/web/pos/moniter vim rrddraw.py #!/usr/bin/env python #coding=utf-8 import rrdtool #ping的图形 def itemping(data): pngname = str(data['pname']) #图

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

__block的本质是变量的二次封装与引用----__forwarding

__block变量的操作: 1.型变操作:在编译时型变为结构体: 2.在复制时,引发本体转移和分身问题. 3.__forwarding的类型为型变类型:指向型变本体. 4.在形式上与变量的深浅拷贝有一定相似之处. __block的本质是变量的二次封装与引用 在编译时编译成封装的结构体. __block结构体变量的本体与分身. 本体转移. struct __Block_byref_val_0 { void *__isa; __Block_byref_val_0 *__forwarding; int