sent_http_HEADER Volatile under Nginx 1.2.4
Paul Taylor
me at ptylr.com
Mon Dec 16 09:22:25 UTC 2013
Yup, again, you’re right! I’ve moved the config around, so that I’m testing for any ‘true’ value in the proxy_no_cache & proxy_bypass_cache directives (removing the existing set_by_lua block).
However, it’s still not behaving as I’d expect.
In the following scenario (note comments):
map $upstream_http_x_no_cache $no_cache_header {
"" 0;
default 1;
}
proxy_cache_bypass $no_cache_dirs $logged_in; # $no_cache_header;
proxy_no_cache $no_cache_dirs $logged_in; # $no_cache_header;
X-Cache-Status value is MISS, which is correct. Output of $no_cache_header is 1 (as set in the map).
However, when adding back in the compare on $no_cache_header:
proxy_cache_bypass $no_cache_dirs $logged_in $no_cache_header;
proxy_no_cache $no_cache_dirs $logged_in $no_cache_header;
X-Cache-Status value is still MISS, which is not correct, as it should be BYPASS. Output of $no_cache_header is 0.
Unless I’m missing something, it still looks like touching the variable kills it?
Thanks again,
Paul
On 13 Dec 2013, at 16:31, Maxim Dounin <mdounin at mdounin.ru> wrote:
> Hello!
>
> On Thu, Dec 12, 2013 at 11:36:21PM +0000, Paul Taylor wrote:
>
>> Hi Maxim,
>> Thanks for your response. You’re right! Using the map did work
>> (I thought I’d tried that, but must have been tired!).
>> So, now I have one other challenge, the value of $foo that you
>> define below is needed to identify whether to cache the response
>> of not. The only issue is that I have a number of other
>> directives that I also need to add into the mix - therefore I
>> use the set_by_lua code to nest/combine OR within an if
>> statement…code below (I’ve kept the variable name as foo, so
>> it’s clear which I’m referring to):
>> map $upstream_http_x_no_cache $foo {
>> "" 0;
>> default 1;
>> }
>> set_by_lua $bypass_cache '
>> local no_cache_dirs = tonumber(ngx.var.no_cache_dirs) or 0
>> local logged_in = tonumber(ngx.var.logged_in) or 0
>> local no_cache_header = tonumber(ngx.var.foo) or 0
>>
>> if((no_cache_dirs == 1) or (no_cache_header == 1) or
>> (logged_in == 1)) then
>> return 1;
>> end
>>
>> return 0;
>> ';
>> Now when I make the Lua local variable declaration in order to
>> use it, the value of $upstream_http_x_no_cache is reset to 0,
>> even when it was set as 1 originally. If I comment out the line
>> declaring the local variable within the Lua call, it returns to
>> being a value of 1 again.
>> Am I getting the sequencing of events wrong again? Is there any
>> way that I can get the value of $upstream_http_x_no_cache into
>> this Lua block, or would I need to do it another way?
>
> Are you going to use the result in proxy_no_cache? If yes, you
> can just use multiple variables there, something like this should
> work:
>
> proxy_no_cache $upstream_http_x_no_cache
> $no_cache_dirs
> $logged_in;
>
> See here for details:
>
> http://nginx.org/r/proxy_no_cache
>
>> Thanks very much for your help so far Maxim.
>> Paul
>> __________________________________________________________________
>> Hello!
>>
>> On Thu, Dec 12, 2013 at 07:19:56PM +0000, Paul Taylor wrote:
>>
>>> I’m in the process of making some amends to an environment,
>>> where my upstream servers are sending a custom header
>>> (X-No-Cache), which I need to detect and alter caching rules
>>> within the configuration.
>>>
>>> The custom header is visible within the output, and I can
>>> re-output it as another header through configuration (i.e.
>>> add_header X-Sent-No-Cache $sent_http_x_no_cache; ).
>>>
>>> However, as soon as I perform any type of testing of this custom
>>> header, it disappears.
>>>
>>> For example, if I was to perform a map on the custom header, try
>>> to set an Nginx variable to the value of the header, or test
>>> within an IF statement, any future call to this header is no
>>> longer possible. Additionally any setting or testing of the
>>> header fails.
>>
>> Both "set" and "if" directives you mentioned are executed _before_
>> a request is sent to upstream, and at this point there is no
>> X-No-Cache header in the response. Due to this, using the
>> $sent_http_x_no_cache variable in "set" or "if" will result in an
>> empty value, and this value will be cached for later use.
>>
>> It's not clear what you are trying to do so I can't advise any
>> further, but certainly using the $sent_http_x_no_cache variable in
>> "if" or "set" directives isn't going to work, and this is what
>> causes behaviour you see.
>>
>> Just a map{} should work fine though - as long as you don't try to
>> call the map before the X-No-Cache header is actually available.
>> E.g., something like this should work fine:
>>
>> map $sent_http_x_no_cache $foo {
>> "" empty;
>> default foo;
>> }
>>
>> add_header X-Foo $foo;
>>
>> It might be also a goo idea to use $upstream_http_x_no_cache
>> variable instead, see here:
>>
>> http://nginx.org/en/docs/http/ngx_http_upstream_module.html#variables
>>
>> --
>> Maxim Dounin
>> http://nginx.org/
>>
>
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20131216/8a990e57/attachment-0001.html>
More information about the nginx
mailing list