nginx里面的变量判断问题

twwwwwy · 2013-10-19T20:30:41+00:00

Hello! 2013/10/18 Ping Donghui: > 我在nginx 的ngx_headers_more > 找到您的联系方式&#x...

nginx里面的变量判断问题

twwwwwy

我写了一个配置文件，判断是 if ($upstream_http_content_type ^* "text") 但是却死活不奏效，我把这个变量打印出来看发现是正常(text/css)的。

然后我就怎么也想不通是什么问题了。

然后我又手贱去试了一下 if ($upstream_http_content_type = "") ，却发现是true！！！！！！

是不是不是所有的nginx变量都可以放到if里面去的啊？请教各位大牛~~感谢~~

yaoweibin

On 2013/10/19 20:30, Jones Zhong wrote:

閿熸枻鎷峰啓閿熸枻鎷蜂竴閿熸枻鎷烽敓鏂ゆ嫹閿熸枻鎷烽敓渚ョ》鎷烽敓鏂ゆ嫹閿熷彨璁规嫹閿熸枻鎷?if ($upstream_http_content_type ^* "text") 閿熸枻鎷烽敓鏂ゆ嫹鍗撮敓鏂ゆ嫹閿熺瓔涓嶉敓鏂ゆ嫹鏁堥敓鏂ゆ嫹閿熸彮甯嫹閿熸枻鎷烽敓鏂ゆ嫹閿熸枻鎷烽敓鏂ゆ嫹閿熸帴鈽呮嫹閿熸枻鎷烽敓鏂ゆ嫹閿熸枻鎷烽敓鏂ゆ嫹閿熸枻鎷烽敓鏂ゆ嫹閿?(text/css)閿熶茎鈽呮嫹

鐒堕敓鏂ゆ嫹閿熸彮鎾呮嫹閿熸枻鎷蜂箞涔熼敓璇笉閫氶敓鏂ゆ嫹浠
twwwwwy
斌哥。。乱码了。。

在 2013年10月19日星期六UTC+8下午8时36分50秒，Weibin Yao写道：
On 2013/10/19 20:30, Jones Zhong wrote:

锟斤拷写锟斤拷一锟斤拷锟斤拷锟斤拷锟侥硷拷锟斤拷锟叫讹拷锟斤拷 if ($upstream_http_content_type ^* "text") 锟斤拷锟斤拷却锟斤拷锟筋不锟斤拷效锟斤拷锟揭帮拷锟斤拷锟斤拷锟斤拷锟斤拷锟接★拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟�(text/css)锟侥★拷

然锟斤拷锟揭撅拷锟斤拷么也锟诫不通锟斤拷什么锟斤拷锟斤拷锟剿★拷

然锟斤拷锟斤拷锟斤拷锟街硷拷去锟斤拷锟斤拷一锟斤拷 if ($upstream_http_content_type = "") 锟斤拷却锟斤拷锟斤拷锟斤拷true锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷

锟角诧拷锟角诧拷锟斤拷锟斤拷锟叫碉拷nginx锟斤拷锟斤拷锟斤拷锟斤拷锟皆放碉拷if锟斤拷锟斤拷去锟侥帮拷锟斤拷锟斤拷谈锟轿伙拷锟脚~锟斤拷谢~~

Nginx锟斤拷锟斤拷锟斤拷母锟斤拷锟斤拷锟斤拷锟阶段ｏ拷锟斤拷锟斤拷执锟斤拷 (http://tengine.taobao.org/book/chapter_02.html#id10)锟斤拷

Rewrite
Access
Content
Log

if锟斤拷应锟斤拷锟斤拷Rewrite锟阶段★拷$upstream_xxx锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟紺ontent执锟叫阶讹拷锟矫碉拷锟斤拷锟斤拷锟接︼拷锟斤拷锟斤拷莶趴锟斤拷锟绞癸拷茫锟斤拷锟斤拷锟斤拷锟斤拷锟� Rewrite锟阶讹拷锟斤拷锟矫诧拷锟斤拷锟斤拷锟斤拷锟侥ｏ拷一锟斤拷只锟斤拷锟节硷拷录锟斤拷锟斤拷锟斤拷志锟斤拷Log锟阶段诧拷锟斤拷锟矫得碉拷锟斤拷
-- 
Weibin Yao
Thanks.
yaoweibin
On 2013/10/19 20:30, Jones Zhong wrote:

我写了一个配置文件，判断是 if ($upstream_http_content_type ^* "text") 但是却死活不奏效，我把这个变量打印出来看发现是正常(text/css)的。

然后我就怎么也想不通是什么问题了。

然后我又手贱去试了一下 if ($upstream_http_content_type = "") ，却发现是true！！！！！！

是不是不是所有的nginx变量都可以放到if里面去的啊？请教各位大牛~~感谢~~

Nginx有请求的各个处理阶段，依次执行 (http://tengine.taobao.org/book/chapter_02.html#id10)：

Rewrite
Access
Content
Log

if对应的是Rewrite阶段。$upstream_xxx这个变量是在Content执行阶段拿到后端响应的内容才可以使用，所以它在 Rewrite阶段是拿不到变量的，一般只能在记录访问日志的Log阶段才能用得到。

-- Weibin Yao Thanks.
twwwwwy
恍然大悟！非常感谢。

在 2013年10月19日星期六UTC+8下午9时44分18秒，Weibin Yao写道：
On 2013/10/19 20:30, Jones Zhong wrote:

我写了一个配置文件，判断是 if ($upstream_http_content_type ^* "text") 但是却死活不奏效，我把这个变量打印出来看发现是正常(text/css)的。

然后我就怎么也想不通是什么问题了。

然后我又手贱去试了一下 if ($upstream_http_content_type = "") ，却发现是true！！！！！！

是不是不是所有的nginx变量都可以放到if里面去的啊？请教各位大牛~~感谢~~

Nginx有请求的各个处理阶段，依次执行 (http://tengine.taobao.org/book/chapter_02.html#id10)：

Rewrite
Access
Content
Log

if对应的是Rewrite阶段。$upstream_xxx这个变量是在Content执行阶段拿到后端响应的内容才可以使用，所以它在 Rewrite阶段是拿不到变量的，一般只能在记录访问日志的Log阶段才能用得到。
-- 
Weibin Yao
Thanks.
twwwwwy
不好意思，又有一个问题，想再问一下，如果用map的惰性求值

map $upstream_http_content_type $token {
default $http_cookie;
~*^text/ 0;
}

能否完成这个需求，在content阶段执行判断？
因为我看这个map是在用到时候才执行。
在 2013年10月19日星期六UTC+8下午8时36分50秒，Weibin Yao写道：
On 2013/10/19 20:30, Jones Zhong wrote:

锟斤拷写锟斤拷一锟斤拷锟斤拷锟斤拷锟侥硷拷锟斤拷锟叫讹拷锟斤拷 if ($upstream_http_content_type ^* "text") 锟斤拷锟斤拷却锟斤拷锟筋不锟斤拷效锟斤拷锟揭帮拷锟斤拷锟斤拷锟斤拷锟斤拷锟接★拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟�(text/css)锟侥★拷

然锟斤拷锟揭撅拷锟斤拷么也锟诫不通锟斤拷什么锟斤拷锟斤拷锟剿★拷

然锟斤拷锟斤拷锟斤拷锟街硷拷去锟斤拷锟斤拷一锟斤拷 if ($upstream_http_content_type = "") 锟斤拷却锟斤拷锟斤拷锟斤拷true锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷

锟角诧拷锟角诧拷锟斤拷锟斤拷锟叫碉拷nginx锟斤拷锟斤拷锟斤拷锟斤拷锟皆放碉拷if锟斤拷锟斤拷去锟侥帮拷锟斤拷锟斤拷谈锟轿伙拷锟脚~锟斤拷谢~~

Nginx锟斤拷锟斤拷锟斤拷母锟斤拷锟斤拷锟斤拷锟阶段ｏ拷锟斤拷锟斤拷执锟斤拷 (http://tengine.taobao.org/book/chapter_02.html#id10)锟斤拷

Rewrite
Access
Content
Log

if锟斤拷应锟斤拷锟斤拷Rewrite锟阶段★拷$upstream_xxx锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟紺ontent执锟叫阶讹拷锟矫碉拷锟斤拷锟斤拷锟接︼拷锟斤拷锟斤拷莶趴锟斤拷锟绞癸拷茫锟斤拷锟斤拷锟斤拷锟斤拷锟� Rewrite锟阶讹拷锟斤拷锟矫诧拷锟斤拷锟斤拷锟斤拷锟侥ｏ拷一锟斤拷只锟斤拷锟节硷拷录锟斤拷锟斤拷锟斤拷志锟斤拷Log锟阶段诧拷锟斤拷锟矫得碉拷锟斤拷
-- 
Weibin Yao
Thanks.
agentzh
Hello!

2013/10/19 Jones Zhong:
> 不好意思，又有一个问题，想再问一下，如果用map的惰性求值
>
> map $upstream_http_content_type $token {
>                 default       $http_cookie;
>                 ~*^text/      0;
>         }
>
> 能否完成这个需求，在content阶段执行判断？
> 因为我看这个map是在用到时候才执行。
>

你在 content 阶段读取你这个 $token 变量，就会在 content 阶段执行映射操作了。这不是很自然的么？

当然，值得提醒的是，$upstream_http_content_type 变量只有在当前请求接收到了后端响应的响应头之后，才会有值。

Regards,
-agentzh
twwwwwy

明白了。。感谢春哥。。

在 2013年10月20日星期日UTC+8上午9时49分48秒，agentzh写道：
Hello!

2013/10/19 Jones Zhong:
> 不好意思，又有一个问题，想再问一下，如果用map的惰性求值
>
> map $upstream_http_content_type $token {
> default $http_cookie;
> ~*^text/ 0;
> }
>
> 能否完成这个需求，在content阶段执行判断？
> 因为我看这个map是在用到时候才执行。
>

你在 content 阶段读取你这个 $token 变量，就会在 content 阶段执行映射操作了。这不是很自然的么？

当然，值得提醒的是，$upstream_http_content_type 变量只有在当前请求接收到了后端响应的响应头之后，才会有值。

Regards,
-agentzh

twwwwwy

我想再问个问题，还是有关这个问题的。并且找到一个讨论 http://nginx.2469901.n2.nabble.com/Cache-by-mime-type-td7580925.html
后来我使用proxy_no_cache的时候，是可以奏效的。
而使用proxy_cache_bypass的时候，是无效的。
我猜测proxy_cache_bypass在upstream前执行，而proxy_no_cache在upstream后执行。
然而我在使用proxy_no_cache的时候，nginx会警告最好和proxy_cache_bypass一起用。但是这样一来，map是有缓存特性的，会因为先执行的proxy_cache_bypass而固化成一个空值，请问应该如何处理，是无视警告继续单独用proxy_no_cache吗？

在 2013年10月20日星期日UTC+8上午10时36分15秒，Jones Zhong写道：

明白了。。感谢春哥。。

在 2013年10月20日星期日UTC+8上午9时49分48秒，agentzh写道：
Hello!

2013/10/19 Jones Zhong:
> 不好意思，又有一个问题，想再问一下，如果用map的惰性求值
>
> map $upstream_http_content_type $token {
> default $http_cookie;
> ~*^text/ 0;
> }
>
> 能否完成这个需求，在content阶段执行判断？
> 因为我看这个map是在用到时候才执行。
>

你在 content 阶段读取你这个 $token 变量，就会在 content 阶段执行映射操作了。这不是很自然的么？

当然，值得提醒的是，$upstream_http_content_type 变量只有在当前请求接收到了后端响应的响应头之后，才会有值。

Regards,
-agentzh
agentzh
Hello!

2013/10/20 Jones Zhong:
> 后来我使用proxy_no_cache的时候，是可以奏效的。
> 而使用proxy_cache_bypass的时候，是无效的。

proxy_cache_bypass 是在 ngx_http_upstream_init_request
函数中检查的（即在给后端发送请求之前）。这条配置指令是用来控制 nginx 是否去检查 cache 里面是否有命中。如果 cache
命中的话，proxy 模块就压根不会去访问后端了。

proxy_no_cache 是在 ngx_http_upstream_send_response
函数中检查的（即在接收到后端的响应头以后）。这条配置指令是用来控制是否把后端的响应写入 cache，所以此时后端已经访问过了。

你的 map 计算是基于后端的响应头，所以你只能使用 proxy_no_cache. 因为在检查 proxy_cache_bypass
的配置时，后端还没有访问呢，自然不会有后端的响应头。

> 我猜测proxy_cache_bypass在upstream前执行，而proxy_no_cache在upstream后执行。

它们其实都是 ngx_http_upstream 内部实现的一部分。这里对于你来说重要的是相对于接收到后端响应头这个时间点的先后。

> 然而我在使用proxy_no_cache的时候，nginx会警告最好和proxy_cache_bypass一起用。

简单忽略掉警告好了。当然，你也可以把 proxy_cache_bypass 设为永真，即

    proxy_cache_bypass 1;

这只是会让 proxy 模块对于所有请求都在访问后端之前先检查一下 cache 里是否有命中，无所谓了。

Regards,
-agentzh
twwwwwy

明白了，非常感谢春哥的回复~~

在 2013年10月21日星期一UTC+8上午6时10分26秒，agentzh写道：
Hello!

2013/10/20 Jones Zhong:
> 后来我使用proxy_no_cache的时候，是可以奏效的。
> 而使用proxy_cache_bypass的时候，是无效的。

proxy_cache_bypass 是在 ngx_http_upstream_init_request
函数中检查的（即在给后端发送请求之前）。这条配置指令是用来控制 nginx 是否去检查 cache 里面是否有命中。如果 cache
命中的话，proxy 模块就压根不会去访问后端了。

proxy_no_cache 是在 ngx_http_upstream_send_response
函数中检查的（即在接收到后端的响应头以后）。这条配置指令是用来控制是否把后端的响应写入 cache，所以此时后端已经访问过了。

你的 map 计算是基于后端的响应头，所以你只能使用 proxy_no_cache. 因为在检查 proxy_cache_bypass
的配置时，后端还没有访问呢，自然不会有后端的响应头。

> 我猜测proxy_cache_bypass在upstream前执行，而proxy_no_cache在upstream后执行。

它们其实都是 ngx_http_upstream 内部实现的一部分。这里对于你来说重要的是相对于接收到后端响应头这个时间点的先后。

> 然而我在使用proxy_no_cache的时候，nginx会警告最好和proxy_cache_bypass一起用。

简单忽略掉警告好了。当然，你也可以把 proxy_cache_bypass 设为永真，即

proxy_cache_bypass 1;

这只是会让 proxy 模块对于所有请求都在访问后端之前先检查一下 cache 里是否有命中，无所谓了。

Regards,
-agentzh