Fix test_https_over_http_error on Windows with OpenSSL 3.1+

[julianz-]

test_https_over_http_error started failing in the CI on Windows with Python 3.14 after recent GitHub Actions runner image updates bumped Python 3.14.5 → 3.14.6 and OpenSSL 3.6.2 → 3.6.3 (win25/20260614.167 deployed ~June 19, win22/20260616.203 deployed shortly after).

The test expects record layer failure when IS_ABOVE_OPENSSL31 is True (OpenSSL > 3.1), but with Python 3.14.6 bundling OpenSSL 3.6.3 on Windows both windows-2025 and windows-2022 now return wrong version number instead. This is a known Windows behavior: the TCP reset is surfaced to userspace before OpenSSL fully processes the server's response, causing a different error code to be reported (documented in CPython's own test_ssl.py).

Linux is currently unaffected — Ubuntu 24.04 uses system OpenSSL 3.0.x, so IS_ABOVE_OPENSSL31 is False there and the test falls through to the elif IS_ABOVE_OPENSSL10 branch, which already expects wrong version number.

❓ What kind of change does this PR introduce?

• 🐞 bug fix
• 🐣 feature
• 📋 docs update
• 📋 tests/coverage improvement
• 📋 refactoring
• 💥 other

📋 What is the related issue number (starting with #)

Resolves #645
Closes #655

❓ What is the current behavior? (You can also link to an open issue here)

CI errors:

>       assert expected_substring in ssl_err.value.args[-1]
E       AssertionError: assert 'record layer failure' in '[SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1082)'

e.g.

https://github.com/cherrypy/cheroot/actions/runs/27889445941/job/82595847403?pr=827

❓ What is the new behavior (if this is a feature change)?

📋 Other information:

📋 Contribution checklist:

(If you're a first-timer, check out
[this guide on making great pull requests][making a lovely PR])

• I wrote descriptive pull request text above
• I think the code is well written
• I wrote [good commit messages]
• I have [squashed related commits together][related squash] after
  the changes have been approved
• Unit tests for the changes exist
• Integration tests for the changes exist (if applicable)
• I used the same coding conventions as the rest of the project
• The new code doesn't generate linter offenses
• Documentation reflects the changes
• The PR relates to only one subject with a clear title
  and description in grammatically correct, complete sentences

[read-the-docs-community]

Documentation build overview

📚 cheroot | 🛠️ Build #33276117 | 📁 Comparing 793a4e2 against latest (18f4ba8)

  🔍 Preview build  

2 files changed

± history/index.html
± pkg/cheroot.server/index.html

[codecov]

Codecov Report

❌ Patch coverage is 71.42857% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 78.17%. Comparing base (18f4ba8) to head (793a4e2).
⚠️ Report is 2 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #828      +/-   ##
==========================================
- Coverage   78.19%   78.17%   -0.02%     
==========================================
  Files          41       41              
  Lines        4788     4793       +5     
  Branches      547      549       +2     
==========================================
+ Hits         3744     3747       +3     
- Misses        905      906       +1     
- Partials      139      140       +1     

[webknjaz]

Thanks! I've been meaning to ask you to look into what's changed in the CI env.

See a few notes on the patch inline.

P.S. I wonder how difficult it'd be to have predictable OpenSSL code paths in CI. Is CPython built statically, or can we somehow substitute OpenSSL it uses with something we pre-build? Since we have a few TLS-dependent code paths in runtime, it'd be good to run tests against each of them in CI at some point.

[webknjaz]

Since this patch doesn't fix a bug in Cheroot's runtime, it shouldn't be listed among bugfixes in the change log. Fixing a test is infra work. So it could be a contrib note. Perhaps, a packaging note when we declare that we support new things (like a new Python version, a new OS or a new dep in this case).

Though, feel free to opt out of attaching a change note if it doesn't feel important to surface to the change log audience. You can add the bot:chronographer:skip label and the bot will stop flagging a missing note in the PR.

[julianz-]

Good points. I changed to a contrib note.

Regarding CPython, I get your idea but it sounds complicated. I was thinking before the issue was the version of OpenSSL but apparently macOS 15 CI runners use Python 3.14.6 with the same bundled OpenSSL 3.6.3 as Windows, but unlike Windows, macOS was already returning the correct record layer failure error. So I have modified the code the check for Windows in addition to the OpenSSL version.

[webknjaz]

Could you also symlink this note to 655 and 645, mentioning the prior art/contrib by radez?

[webknjaz]

Yeah, it's probably a good idea to normalize these into a unified check where possible. Maybe, migrating to requests in tests over time would be a better solution than trying to rely on low-level stdlib stuff. But this is something to think about separately.

[julianz-]

I get the intent but wouldn't this make error extraction more complex? requests wraps the SSL error through urllib3, so accessing the underlying message requires a deeper chain than ssl_err.value.args[-1]?

[webknjaz]

This shouldn't be needed since pytest is invoked w/ CLI options that should reveal the vars in scope:

Suggested change

	), actual_error
	)

[webknjaz]

@julianz- I just realized that #655 seems to address the same case: #645. Could you absorb the commit from that PR into your branch, rebasing your structural improvements on top?

If you wish to make a combined commit through interactive rebase, use https://hynek.me/til/easier-crediting-contributors-github/ to give appropriate credit.

[julianz-]

@webknjaz

I just realized that #655 seems to address the same case: #645. Could you absorb the commit from that PR into your branch, rebasing your structural improvements on top?

I looked into rebasing using radez's commit from #655, but your commit 4470ae98 ("🧪 Add OpenSSL 3.2 expectations to tests", pushed directly to main in Feb 2025) already incorporated similar changes — IS_ABOVE_OPENSSL31 in _compat.py and the 3-level test logic in test_ssl.py. So rebasing produces an empty diff.