Thanks @pquentin, this is a great idea!

Based on the following docstring, the library code relevant to the test may work differently in CPython 3.8, 3.9, and in any version with the pyOpenSSL injection.

What do you think about running the test in CPython 3.8, 3.9, and the latest one to make sure that no changes to _fp_read break the method for users of old CPython versions?

Excellent point, thank you. I'm wondering if I should not instead try to monkeypatch the calls that CPython is making to avoid decrypting multiple gigabytes of actual SSL data. If it proves difficult, then I'll run the integration tests on 3.8, 3.9 and latest. How does that sound?

@pquentin I'm curious to see what can be patched to avoid that.

IIRC there are three approaches CPython uses in different versions:

• using SSL_read_ex call in a loop in CPython 3.10+
• using SSL_read call in a loop with the python/cpython@153365d patch
• using SSL_read call in a loop without the patch

They have different consequences for urllib3.

Also, when pyOpenSSL is used, the library is responsible for the decryption.

I'm liking the idea to run it on 3.8, 3.9, and latest if only to speed up every other PRs CI time for now? Quite the improvement, would like to take advantage 👀

I still think the mocking idea could work, but I'd prefer focusing my energy on more useful things! Added 3.8 and 3.9.