$upstream_http_* variables exist but do not seem to be readable

Maxim Dounin mdounin at mdounin.ru
Fri Feb 1 14:48:30 UTC 2013


Hello!

On Fri, Feb 01, 2013 at 08:59:38AM -0500, shrikeh wrote:

> Hi,
> 
> I'm currently using OpenResty, and one of the things I am trying to do is
> have the backend send a specific header, and if that header is present, run
> a body_filter_by_lua call on the output. However, while I can use the
> $upstream_http_* vars for populating (i.e. I can go add_header SomeHeader
> $upstream_http_foo, and if Foo has been sent see SomeHeader: FooVar in the
> output. However, all tests for them seem to break.
> 
> Example:
> 
> location @backend {
> 		expires off;
> 		proxy_pass http://_varnish;
>                 set $test $upstream_http_csrf; # definitely exists, I can
> see it in the response headers

The "set" directive is rewrite module directive, and it is 
executed during the rewrite request processing phase, which 
happens before a request is passed to the upstream.

Unless the request was previusly processed using an upstream 
server, the $test variable will be empty.

>                 add_header SomeHeader $upstream_http_csrf; # And I can read
> it, but....

This will work.

>                 if ($upstream_http_csrf = 1) { # doesn't matter if it's 1,
> "one" ~* "one", anything....
>                 # this block never gets called
>                 }

This won't, for the same reasons as outlined above - the "if" 
directive can't see upstream response headers as it's executed 
before a response is available.

>                 add_header someOtherHeader $test; # Not present in output as
> empty

See above.

> 		set_by_lua $use_token
> 		'
> 		if not ngx.var.sent_http_csrf  == "" then
> 			return ngx.var.upstream_http_csrf
> 		end
> 		return "baz"
> 		'; # Always return 'baz'
>                 add_header WIllThisWork $use_token; # Again, empty

I'm not familiar with lua module, but likely the explanation is 
the same - set_by_lua is executed before a response is available.

-- 
Maxim Dounin
http://nginx.com/support.html



More information about the nginx mailing list