网站制作替我们购买域名,有什么做外贸的网站,顺德做营销网站公司,青岛市工程建设信息网站也有一些内建变量是支持改写的#xff0c;其中一个例子是 $args. 这个变量在读取时返回当前请求的 URL 参数串(即请求 URL 中问号后面的部分#xff0c;如果有的话 )#xff0c;而在赋值时可以直接修改参数串。我们来看一个例子#xff1a;location /test { set $orig_args…也有一些内建变量是支持改写的其中一个例子是 $args. 这个变量在读取时返回当前请求的 URL 参数串(即请求 URL 中问号后面的部分如果有的话 )而在赋值时可以直接修改参数串。我们来看一个例子 location /test { set $orig_args $args; set $args a3b4; echo original args: $orig_args; echo args: $args; }这里我们把原始的 URL 参数串先保存在 $orig_args 变量中然后通过改写 $args 变量来修改当前的 URL 参数串最后我们用 echo 指令分别输出 $orig_args 和 $args 变量的值。接下来我们这样来测试这个 /test 接口 $ curl http://localhost:8080/test original args: args: a3b4 $ curl http://localhost:8080/test?a0b1c2 original args: a0b1c2 args: a3b4在第一次测试中我们没有设置任何 URL 参数串所以输出 $orig_args 变量的值时便得到空。而在第一次和第二次测试中无论我们是否提供 URL 参数串参数串都会在 location /test 中被强行改写成 a3b4.需要特别指出的是这里的 $args 变量和 $arg_XXX 一样也不再使用属于自己的存放值的容器。当我们读取 $args 时Nginx 会执行一小段代码从 Nginx 核心中专门存放当前 URL 参数串的位置去读取数据而当我们改写 $args 时Nginx 会执行另一小段代码对相同位置进行改写。Nginx 的其他部分在需要当前 URL 参数串的时候都会从那个位置去读数据所以我们对 $args 的修改会影响到所有部分的功能。我们来看一个例子 location /test { set $orig_a $arg_a; set $args a5; echo original a: $orig_a; echo a: $arg_a; }这里我们先把内建变量 $arg_a 的值即原始请求的 URL 参数 a 的值保存在用户变量 $orig_a 中然后通过对内建变量 $args 进行赋值把当前请求的参数串改写为 a5 最后再用 echo 指令分别输出 $orig_a 和 $arg_a 变量的值。因为对内建变量 $args 的修改会直接导致当前请求的 URL 参数串发生变化因此内建变量 $arg_XXX 自然也会随之变化。测试的结果证实了这一点 $ curl http://localhost:8080/test?a3 original a: 3 a: 5我们看到因为原始请求的 URL 参数串是 a3, 所以 $arg_a 最初的值为 3, 但随后通过改写 $args 变量将 URL 参数串又强行修改为 a5, 所以最终 $arg_a 的值又自动变为了 5.我们再来看一个通过修改 $args 变量影响标准的 HTTP 代理模块 ngx_proxy 的例子 server { listen 8080; location /test { set $args foo1bar2; proxy_pass http://127.0.0.1:8081/args; } } server { listen 8081; location /args { echo args: $args; } }这里我们在 http 配置块中定义了两个虚拟主机。第一个虚拟主机监听 8080 端口其 /test 接口自己通过改写 $args 变量将当前请求的 URL 参数串无条件地修改为 foo1bar2. 然后 /test 接口再通过 ngx_proxy 模块的 proxy_pass 指令配置了一个反向代理指向本机的 8081 端口上的 HTTP 服务 /args. 默认情况下ngx_proxy 模块在转发 HTTP 请求到远方 HTTP 服务的时候会自动把当前请求的 URL 参数串也转发到远方。而本机的 8081 端口上的 HTTP 服务正是由我们定义的第二个虚拟主机来提供的。我们在第二个虚拟主机的 location /args 中利用 echo 指令输出当前请求的 URL 参数串以检查 /test 接口通过 ngx_proxy 模块实际转发过来的 URL 请求参数串。我们来实际访问一下第一个虚拟主机的 /test 接口 $ curl http://localhost:8080/test?blah7 args: foo1bar2我们看到虽然请求自己提供了 URL 参数串 blah7但在 location /test 中参数串被强行改写成了 foo1bar2. 接着经由 proxy_pass 指令将我们被改写掉的参数串转发给了第二个虚拟主机上配置的 /args 接口然后再把 /args 接口的 URL 参数串输出。事实证明我们对 $args 变量的赋值操作也成功影响到了 ngx_proxy 模块的行为。在读取变量时执行的这段特殊代码在 Nginx 中被称为“取处理程序”(get handler)而改写变量时执行的这段特殊代码则被称为“存处理程序”(set handler)。不同的 Nginx 模块一般会为它们的变量准备不同的“存取处理程序”从而让这些变量的行为充满魔法。其实这种技巧在计算世界并不鲜见。比如在面向对象编程中类的设计者一般不会把类的成员变量直接暴露给类的用户而是另行提供两个方法(method)分别用于该成员变量的读操作和写操作这两个方法常常被称为“存取器”(accessor)。下面是 C 语言中的一个例子 #include using namespace std; class Person { public: const string get_name() { return m_name; } void set_name(const string name) { m_name name; } private: string m_name; };在这个名叫 Person 的 C 类中我们提供了 get_name 和 set_name 这两个公共方法以作为私有成员变量 m_name 的“存取器”。这样设计的好处是显而易见的。类的设计者可以在“存取器”中执行任意代码以实现所需的业务逻辑以及“副作用”比如自动更新与当前成员变量存在依赖关系的其他成员变量抑或是直接修改某个与当前对象相关联的数据库表中的对应字段。而对于后一种情况也许“存取器”所对应的成员变量压根就不存在或者即使存在也顶多扮演着数据缓存的角色以缓解被代理数据库的访问压力。与面向对象编程中的“存取器”概念相对应Nginx 变量也是支持绑定“存取处理程序”的。Nginx 模块在创建变量时可以选择是否为变量分配存放值的容器以及是否自己提供与读写操作相对应的“存取处理程序”。不是所有的 Nginx 变量都拥有存放值的容器。拥有值容器的变量在 Nginx 核心中被称为“被索引的”(indexed)反之则被称为“未索引的”(non-indexed)。我们前面在 (二) 中已经知道像 $arg_XXX 这样具有无数变种的变量群是“未索引的”。当读取这样的变量时其实是它的“取处理程序”在起作用即实时扫描当前请求的 URL 参数串提取出变量名所指定的 URL 参数的值。很多新手都会对 $arg_XXX 的实现方式产生误解以为 Nginx 会事先解析好当前请求的所有 URL 参数并且把相关的 $arg_XXX 变量的值都事先设置好。然而事实并非如此Nginx 根本不会事先就解析好 URL 参数串而是在用户读取某个 $arg_XXX 变量时调用其“取处理程序”即时去扫描 URL 参数串。类似地内建变量 $cookie_XXX 也是通过它的“取处理程序”即时去扫描 Cookie 请求头中的相关定义的。
