On Fri, Sep 17, 2021 at 03:50:20PM +0200, Javier wrote:
On Fri, 17 Sep 2021 11:32:01 +0900 Haruka Takagi <takagiharuka0000@gmail.com> wrote:
Thank you for your reply.
I meant 503 service unavailable response to stunnel client's CONNECT request, not to original sender's GET or POST request. I hope that stunnel clients retry CONNECT after 503.
I tried "retry = yes" configuration, but stunnel clients did not work as I had expected.
Can I adopt another approach?
Hi,
Stunnel won't recive an HTTP 503 because isn't aware of it and so won't retry a connection because the connection is up and alive.
See my other reply (sorry, something was wrong with my mail setup so it only went out now despite having been written yesterday). The original poster is asking about the case when stunnel uses an HTTP/HTTPS proxy and sends a CONNECT request to it (the proxy) to establish the socket connection with the other side. It then negotiates TLS over the established proxied connection, but it has to parse the proxy's HTTP response to the CONNECT request first. Hence, if the proxy gives an HTTP 503 "I could not connect to the actual server" response, stunnel considers the connection attempt failed and closes the client connection, too. G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@debian.org pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13