Align SSL adapters by removing bind()

[julianz-]

Relocated SSLConnection instantiation from bind() to wrap() to provide a uniform adapter interface, in which wrap() is responsible for converting raw sockets to SSL connections. With this change bind() serves no purpose and so is deprecated. This change also fixes the pyOpenSSL adapter so that it doesn't prematurely wrap the raw socket, an issue in the old bind() implementation.

[codecov]

Codecov Report

❌ Patch coverage is 97.50000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 77.55%. Comparing base (a475500) to head (3ac86f1).
⚠️ Report is 2 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #801      +/-   ##
==========================================
- Coverage   77.69%   77.55%   -0.14%     
==========================================
  Files          41       41              
  Lines        4672     4688      +16     
  Branches      544      542       -2     
==========================================
+ Hits         3630     3636       +6     
- Misses        900      909       +9     
- Partials      142      143       +1     

[julianz-]

@webknjaz This PR is failing in some instances running test_http_over_https_error e.g.: "ERROR at teardown of test_http_over_https_error[::-builtin]." The problem seems to arise only with the builtin adapter because this forces a handshake in wrap() and after the handshake fails the state of the socket is dead running on my Mac (fd=-1). In some other environments the test seems to pass in the CI, so I guess the socket can still be usable but it depends - maybe there is a race condition. Anyway, I can fix this issue by overriding _flush_unlocked() in StreamWriter. This is more of bug fix though so should probably go in a different PR. With that fix, I suspect the test becomes less flaky too. Thoughts?

[webknjaz]

Anyway, I can fix this issue by overriding _flush_unlocked() in StreamWriter. This is more of bug fix though so should probably go in a different PR. With that fix, I suspect the test becomes less flaky too. Thoughts?

Not sure. I've suspected race conditions in some places. I think I've also seen some of these happening under pytest because we turn warnings into errors in there. So when some cleanup is not deterministic, the destructors on things like sockets issue resource warnings that cascade further and perhaps even affect the control flow in such conditions. This is probably why

cheroot/pytest.ini

Lines 55 to 58 in a475500

	# FIXME: Try to figure out what causes this and ensure that the socket
	# FIXME: gets closed.
	ignore:unclosed <socket.socket fd=:ResourceWarning
	ignore:unclosed <ssl.SSLSocket fd=:ResourceWarning

has ignores.

It would definitely need a dedicated PR but I'd rather focus on finishing this refactoring first. If you're worried about the 3.14 jobs — they all are marked as allowed to fail and fixing that would be a separate effort. Maybe, there's something in your #770 / #779 that will help eventually but right now, let's not bother and focus on the stable envs first.

As a part of adding Python 3.14 support and figuring out the flakiness, we'll need to look at how to handle the ignored warnings.

The reason these fail under Python 3.14 is that it seems like the warning messages changed slightly. They match what Python 3.13 emits and so are ignored in those jobs. This is probably a short-term workaround: https://github.com/cherrypy/cheroot/pull/780/files#diff-fb6a686182f16eb54af3c628f38593f347f68aba31de903983023c560288d7a1R65. That PR seems incomplete and abandoned but a few ideas in there give out some clues.

[julianz-]

@webknjaz

If you're worried about the 3.14 jobs — they all are marked as allowed to fail and fixing that would be a separate effort.

Interestingly, I am able to repro the error with 100% reliability on MacOS using Python v3.12. I notice that the test excludes MacOS with the builtin adapter for reasons that were not well explained in #225 apart from the fact that the test wouldn't pass! I am tempted to do a new PR and you can see for yourself. The fix is pretty simple. There's no reason to exclude MacOS anymore too.

[webknjaz]

I tempted to do a new PR and you can see for yourself. The fix is pretty simple. There's no reason to exclude MacOS anymore too.

Looking forward!

[webknjaz]

Wonderful, thanks!