Disguising HTTP 503 services unavailable
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. 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-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
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? 2021年9月17日(金) 3:44 Norbert Hanke <[email protected]>:
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. 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-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ stunnel-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
On Fri, Sep 17, 2021 at 11:32:01AM +0900, Haruka Takagi wrote:
2021年9月17日(金) 3:44 Norbert Hanke <[email protected]>:
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 -- Peter Pentchev [email protected] [email protected] [email protected] PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
On Fri, 17 Sep 2021 11:32:01 +0900 Haruka Takagi <[email protected]> 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. Stunnel makes a TLS handsake with the server. The server routes the connection to the service behind, in your case a web server. The server replies is unavailable. Stunnel keeps connection with the server. The reply is sent back to the program that used Stunnel in client mode to establish a TLS connection to the server. The program must decide to reconnect. Stunnel connection is still alive expecting more traffic to send back and forth. In other words, you can't instruct Stunnel to deal with an HTTP error response. That is up to the program that is using Stunnel. Even if the connection is being reset by the server, instruct Stunnel to retry will give the same result, the HTTP server behind will tell is unavailable. The only approach is to setup the program using Stunnel in client mode to deal with HTTP 503 accordingly. Unless you are using the "proto = connect" option and that is another story... I don't know how it deals with HTTP error codes, but, nowadays, I think upgrade HTTP to HTTPS is not very common... Regards.
On Fri, Sep 17, 2021 at 03:50:20PM +0200, Javier wrote:
On Fri, 17 Sep 2021 11:32:01 +0900 Haruka Takagi <[email protected]> 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 [email protected] [email protected] [email protected] PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
participants (4)
-
Haruka Takagi -
Javier -
Norbert Hanke -
Peter Pentchev