On Fri, Sep 17, 2021 at 11:32:01AM +0900, Haruka Takagi wrote:
2021年9月17日(金) 3:44 Norbert Hanke norbert.hanke@gmx.ch:
On 16.09.2021 19:29, Haruka Takagi wrote:
It is my understanding that; stunnel clients give up connecting servers because of HTTP 503 services unavailable, tunneling failure causes stunnel clients to notify original senders of errors, and original senders acknowledge communication failure and stop program.
I would like stunnel clients to reconnecting servers in cases of 503 and not to notify original senders of failure, in order that original senders are unaware of failure and can continue program.
If possible, I want to do this by writing stunnel.conf without modifying souce codes.
Is this configuration possible?
stunnel acts strictly on the TLS level. It is not aware of the meaning of the payload that gets moved through the tunnel. No matter if that is HTTP, LDAP, SMTP, whatever.
If there is an HTTP 503 response from a server that will end up on the client as-is.
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.
To answer your direct question, stunnel will only proceed if the HTTP response to the CONNECT request is 2xx (the range of HTTP responses indicating successful processing of the request). Anything else is treated as an error while establishing the connection. To change that, changes in the stunnel source code would be necessary, but IMHO, especially if the Retry-After header is supposed to be followed, those changes may turn out to be quite extensive - implementing an actual parser for HTTP response headers instead of the current "read until an empty line is encountered" one. Obviously, I cannot speak for the stunnel developers as to whether they would consider doing something like that.
On the other hand, naively retrying after a fixed period of time (possibly with exponential backoff) on a 503 or 504 (and no other) response might not be too difficult... but again, it is not my decision to make.
G'luck, Peter