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