infinite loop until server fails in upstream module with round robin

[unixant@…]

I use nginx as a load balancing for backend web server.
if this upstream has n servers,and m backup servers,and the n servers are not available(Connection refused),round robin will try n*max_fails times to connect to the n servers。but if there is no backup servers,round robin only try n times to the n servers.
such as:

upstream bdbk {

#no program listen on 8081,8082

server 127.0.0.1:8081 max_fails=3 fail_timeout=10s;
server 127.0.0.1:8082 max_fails=3 fail_timeout=10s;

server 127.0.0.1:8083 max_fails=3 fail_timeout=10s backup;
server 127.0.0.1:8084 max_fails=3 fail_timeout=10s backup;

}

if i make a request,upstream try 6(n*max_fails) to connect to 8081 8082 , then round robin try to connect to backup server.

if there is no backup servers。nginx only try 2(n) connect to 8081 8082。

[Maxim Dounin]

This a variation of #47.

[Sergey Kandaurov <pluknet@…>]

In 9302:bb4f30755c57/nginx:

SSL: optional ssl_client_certificate for ssl_verify_client.

Starting from TLSv1.1 (as seen since draft-ietf-tls-rfc2246-bis-00),
the "certificate_authorities" field grammar of the CertificateRequest
message was redone to allow no distinguished names. In TLSv1.3, with
the restructured CertificateRequest message, this can be similarly
done by optionally including the "certificate_authorities" extension.
This allows to avoid sending DNs at all.

In practice, aside from published TLS specifications, all supported
SSL/TLS libraries allow to request client certificates with an empty
DN list for any protocol version. For instance, when operating in
TLSv1, this results in sending the "certificate_authorities" list as
a zero-length vector, which corresponds to the TLSv1.1 specification.
Such behaviour goes back to SSLeay.

The change relaxes the requirement to specify at least one trusted CA
certificate in the ssl_client_certificate directive, which resulted in
sending DNs of these certificates (closes #142). Instead, all trusted
CA certificates can be specified now using the ssl_trusted_certificate
directive if needed. A notable difference that certificates specified
in ssl_trusted_certificate are always loaded remains (see 3648ba7db).

Co-authored-by: Praveen Chaudhary <praveenc@…>