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.
>