Dispatch WRITE_COMPLETE when TLS handshake completes#11574
Merged
bneradt merged 1 commit intoapache:masterfrom Jul 19, 2024
Merged
Dispatch WRITE_COMPLETE when TLS handshake completes#11574bneradt merged 1 commit intoapache:masterfrom
bneradt merged 1 commit intoapache:masterfrom
Conversation
Contributor
|
Fixes #11552. |
maskit
reviewed
Jul 18, 2024
The SSLNetVConnection.cc logic already does this, so this is a port over of that event dispatch functionality when ntodo is 0 for UnixNetVConnection.cc. @JosiahWI and I investigated a periodic failure in proxy_protocol.test.py and we noticed that the issue was due to the handshake completing within a single call of sslStartHandshake. In those cases, the ConnectingEntry handler wasn't called back and the connection would hang without progressing with the rest of the request after the handshake completed. This ensures that the ConnectingEntry handler is called in these circumstances.
bneradt
force-pushed
the
fix_proxy_protocol_over_tls_hangs
branch
from
b6905c9 to
780a42a
Compare
bneradt
changed the title
maskit
approved these changes
Jul 18, 2024
Contributor
|
Cherry-picked to v10.0.x |
cmcfarlen
pushed a commit
that referenced
this pull request
Jul 21, 2024
The SSLNetVConnection.cc logic already does this, so this is a port over of that event dispatch functionality when ntodo is 0 for UnixNetVConnection.cc. @JosiahWI and I investigated a periodic failure in proxy_protocol.test.py and we noticed that the issue was due to the handshake completing within a single call of sslStartHandshake. In those cases, the ConnectingEntry handler wasn't called back and the connection would hang without progressing with the rest of the request after the handshake completed. This ensures that the ConnectingEntry handler is called in these circumstances. (cherry picked from commit de2c354)
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
4 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.
The SSLNetVConnection.cc logic already does this, so this is a port over
of that event dispatch functionality when ntodo is 0 for
UnixNetVConnection.cc. @JosiahWI and I investigated a periodic failure
in proxy_protocol.test.py and we noticed that the issue was due to the
handshake completing within a single call of sslStartHandshake. In those
cases, the ConnectingEntry handler wasn't called back and the connection
would hang without progressing with the rest of the request after the
handshake completed. This ensures that the ConnectingEntry handler is
called in these circumstances.
Review Comments
SSLNetVConnection Reference
For reference, here is the corresponding dispatch from SSLNetVConnection that does this callback as well:
trafficserver/src/iocore/net/SSLNetVConnection.cc
Lines 690 to 694 in 5f29d55
This patch simply pulls in that callback for UnixNetVConnection's TLS handshake handling logic.
Testing
The proxy_protocol.test.py test demonstrates this infrequently in ASF CI. I have never seen this locally on my mac. I've run this test in CI using my access to the CI vms dozens of times and have not seen a failure. I have been able to reproduce the error fairly consistently before this patch, so I feel this addresses the issue well.