sent_http_HEADER Volatile under Nginx 1.2.4

[Maxim Dounin]

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/