Waow.
I am off-topic, but Valentin I shall note you are showing a great deal of
patience.
Without any doubt your interlocutor will be glad and thankful for it, and
will demonstrate it as good as when he (quickly) becomes upset.
Btw, I do not know any Captain Evidence, only Captain Obvious.
---
*B. R.*
On Wed, Apr 13, 2016 at 10:05 AM, Валентин Бартенев <vb...@nginx.com> wrote:
> On Wednesday 13 April 2016 00:47:14 drookie wrote:
> > Is there someone besides Captain Evidence who knows the answer ? This is
> > actually the problem of the modern internet: half of the decent
> questions is
> > flooded out by people, who not only think they know the answer, but are
> > arrogant enough to insist it, and from the point of an outer observer the
> > topic looks "answered".
> >
> [..]
>
> Ok, probably "fastcgi_next_upstream" in my answer misled you, since nginx
> with
> the "upstream" block for sure talks to other nginx instances by HTTP using
> "proxy_pass", then "proxy_next_upstream" would the correct answer in this
> case.
>
> In the configuration below:
>
> upstream backends {
> server 192.168.0.1;
> server 192.168.0.2;
> }
>
> proxy_pass http://backends;
>
> nginx doesn't care (and knows nothing) about the virtual hosts presented on
> these servers in the upstream block, and don't try to differentiate
> requests
> in terms of liveness using the host header or any other parameter.
>
> If the "192.168.0.1" will be recognized as dead by the rules that are
> described in the documentation, it will be considered dead for all requests
> for all hosts that use this upstream block.
>
> So the "member liveness" is per upstream group.
>
> What I also wanted to bring to your attention is that by default the 500
> response isn't recognized as a fail attempt, unless you have configured it
> using the proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream,
> or scgi_next_upstream directives (depending on the protocol).
>
> wbr, Valentin V. Bartenev
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
