Set a higher timeout for proxyproto listeners#33
Merged
emersion merged 1 commit intoemersion:masterfrom Sep 19, 2021
Merged
Conversation
go-proxyproto added support for a read timeout in 0.6.0[1] and defaulted it to 200ms. After this time if no data is read on the socket, it is closed. This is _really_ low if the underlying connection is a TLS one as no data pops out the other end until the handshake is done. It effectively limits you to TLS connections within a 50ms RTT of your bouncer with clients that are fast enough at responding. It appears that HexChat on Arch is somehow slow enough at TLS connections thant it consistently takes longer than 200ms even over localhost, meaning it outright can't connect to soju any longer. To make this a lot less painful, have soju pass in a read timeout of 5 seconds. This feels like a reasonable tradeoff between keeping (possibly malicious) connections open and accepting the realities of network connections. [1]: pires/go-proxyproto#65
Owner
|
Opened pires/go-proxyproto#83 to see how upstream feels about this. |
freebsd-git
pushed a commit
to freebsd/freebsd-ports
that referenced
this pull request
Sep 19, 2021
This is bug fix related to using it over VPN, or behind a reverse proxy. See https://todo.sr.ht/~emersion/soju/134, and emersion/soju#33.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
go-proxyproto added support for a read timeout in 0.6.01 and
defaulted it to 200ms. After this time if no data is read on
the socket, it is closed.
This is really low if the underlying connection is a TLS
one as no data pops out the other end until the handshake is
done. It effectively limits you to TLS connections within
a 50ms RTT of your bouncer with clients that are fast enough
at responding.
It appears that HexChat on Arch is somehow slow enough at
TLS connections thant it consistently takes longer than
200ms even over localhost, meaning it outright can't connect
to soju any longer.
To make this a lot less painful, have soju pass in a read
timeout of 5 seconds. This feels like a reasonable tradeoff
between keeping (possibly malicious) connections open and
accepting the realities of network connections.