-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
elli_tcp: cast 'accepted' AFTER TLS handshake succeeded #90
Conversation
Thanks. This looks good to me. Would you be willing to add a test or two? Ideally they would fail before this patch and succeed after. |
192a7ab
to
74f0b0d
Compare
Not done yet. I have to find a solution for OTP-20 and older where ssl:connect/3 in acceptor_leak_regression succeeds despite the verify and verify_fun options. |
74f0b0d
to
0d484f4
Compare
0d484f4
to
d6f6d50
Compare
OTP-20 and older reuse TLS sessions even when the (verify) connect options have changed. Since other successful tests might leave a reusable TLS session, one has to set
BTW:
to
|
Maybe we should prefer |
I say we merge this and patch the application start/stop shortly after. I'll add this to my Wednesday evening session too heh |
This looks good to me, and I've confirmed Given that rebar3 starts What do you think, @tsloughter? |
Using I've wanted to move tests to Common Test since I think it has much clearer semantics for all this (and better error messages for where a failure happened in the tests).. but it would be a lot of work probably. |
Maybe I'll start with adding a common test suite and over time cases can be moved to it. |
Merging this for now then, and we can handle the move to CT in another (series of) PR(s). Thanks, @sg2342! |
fix #84