ssl: Correct connection state handling in TLS sender #10201
Conversation
11be4f9 to
538178c
Compare
2a08c91 to
c969142
Compare
CT Test Results 38 files 1 006 suites 7h 23m 10s ⏱️ For more details on these failures, see this check. Results for commit 0d8cf06. ♻️ This comment has been updated with latest results. To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts// Erlang/OTP Github Action Bot |
c969142 to
570685f
Compare
570685f to
dde2b54
Compare
Optimization commit 28f7e80 broke max_fragment_length handling, that is the TLS sender lost its knowledge of the maximum fragment length. Make TLS sender process aware of it in the cases it is negotiated, for default maximum we do not need to store it in the connection state. Closes erlang#10191
dde2b54 to
0d8cf06
Compare
|
Thanks for the fix. Since this PR is fixing a regression that was introduced during an optimization, could you please add a test case that covers this scenario? Without a regression test, we risk the same issue creeping back in the future when performance-related changes are made again. A targeted test would both validate this fix and serve as protection against similar regressions. |
|
Yes we will be adding a regression test. We are working on some property based tests where this is easy to test, this is not ready for production yet. It could be possible with an awkward white-box test but we will put our efforts into the property based test instead, so it is coming. |
Optimization commit 28f7e80 broke max_fragment_length handling, that is the TLS sender lost its knowledge of the maximum fragment length.
Make TLS sender process aware of it in the cases it is negotiated, for default maximum we do not need to store it in the connection state.
Closes #10191