proxy_set_header variable evaluation
Maxim Dounin
mdounin at mdounin.ru
Wed Aug 26 23:19:03 MSD 2009
Hello!
On Thu, Aug 27, 2009 at 12:04:33AM +0530, Arvind Jayaprakash wrote:
> I am trying to do some tricks with upstream+proxy and ran into what
> seems like a limitation of the proxy_set_header feature.
>
> When an upstream's response triggers resending the request to the next
> upsteam, I was hoping $upstream_response_time is available with data of
> what happened in the previous upsteams. I'm trying to pass it using the
> following directive:
>
> proxy_set_header X-retry1 $upstream_response_time;
>
> It looks like the variable is always unavailable (even when when nginx
> tries to access the second upstream for the same request). However, the
> value seems to be available during the logging phase.
This won't work because request to backend server created only
once - and then nginx just tries to send the same request to
available upstreams.
You may want to use error_page fallback instead of
proxy_next_upstream, this will allow you to recreate request with
new headers. Note that you have to save $upstream_request_time to
some temporary variable before upstream module will start again -
as it will reset all related data. E.g.
upsteam backend {
server 192.168.1.1:80;
server 192.168.1.2:80;
...
}
server {
...
proxy_next_upstream off;
location / {
error_page 502 504 = @fallback;
proxy_pass http://backend;
}
location @fallback {
set $blah $upstream_response_time;
proxy_pass http://backend;
proxy_set_header X-Blah $blah;
}
}
Note that you may use arbitrary fallback chain this way (including
usage of spare backends and so on).
Maxim Dounin
>
> I tried recompiling with the response variable marked as uncachable (v->no_cacheable = 1) but that did not seem to help.
>
> The question is if this is a limitation of proxy_set_header or upstream
> variables? I got a feeling that $upstream_response_time is evaluated
> once before the upstreams are tried and evalutes to "not found" and not
> re-evaluated for each upstream attempt.
>
More information about the nginx
mailing list