Skip to content

Fix test_https_over_http_error on Windows with OpenSSL 3.1+ #828

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.

Sign up for GitHub

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

Open
julianz- wants to merge 2 commits into
base: main
Choose a base branch
from
+15 −8
Open

Fix test_https_over_http_error on Windows with OpenSSL 3.1+ #828

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2a8fc12
Fix test_https_over_http_error on Windows with OpenSSL 3.1+
julianz- Jun 21, 2026
5bc6aef
Simplify test_https_over_http_error assertions and error handling
julianz- Jul 13, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 23 additions & 9 deletions cheroot/test/test_ssl.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -527,7 +527,9 @@ def test_tls_client_auth( # noqa: C901, WPS213 # FIXME
"'Remote end closed connection without response'))",
)

assert any(e in err_text for e in expected_substrings)
assert any(e in err_text for e in expected_substrings), (
f'Unexpected error text: {err_text!r}'

@webknjaz webknjaz Jul 12, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@julianz- why did you think this was necessary? pytest should already expose this automatically.

@julianz- julianz- Jul 12, 2026 •
edited
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had a failure and for some reason could not see what the failure was but you're right - it's not needed.

)


@pytest.mark.parametrize( # noqa: C901 # FIXME
Expand Down Expand Up @@ -697,14 +699,26 @@ def test_https_over_http_error(http_server, ip_addr):
http.client.HTTPSConnection(
f'{interface}:{port}',
).request('GET', '/')
expected_substring = (
'record layer failure'
if IS_ABOVE_OPENSSL31
else 'wrong version number'
if IS_ABOVE_OPENSSL10
else 'unknown protocol'
)
assert expected_substring in ssl_err.value.args[-1]
underlying_error_string = str(ssl_err.value)
if IS_ABOVE_OPENSSL31 and IS_WINDOWS:

@webknjaz webknjaz Jul 7, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@julianz- looks like it's not just Windows: https://github.com/cherrypy/cheroot/actions/runs/28048216203/job/83032035095?pr=828#step:15:131

@webknjaz webknjaz Jul 12, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps, we could just keep the first two blocks (if+elif) as one if-block w/o distinguishing by whether this is windows? Just merge them but keep the explanatory comments. WDYT?

@julianz- julianz- Jul 13, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes makes sense

# On Windows, the TCP reset (RST) is surfaced before OpenSSL processes
# the server's response, yielding 'wrong version number' rather than
# the usual 'record layer failure'. See CPython's own test_ssl.py:
# https://github.com/python/cpython/blob/\
# 1b9fe5c7226eccc8b269a7443148033080399f43\
# /Lib/test/test_ssl.py#L5705
assert 'wrong version number' in underlying_error_string
elif IS_ABOVE_OPENSSL31:
# Newer Python returns 'record layer failure'; Python 3.8 on macOS
# returns 'wrong version number' despite OpenSSL >= 3.1.
assert (
'record layer failure' in underlying_error_string
or 'wrong version number' in underlying_error_string
)
elif IS_ABOVE_OPENSSL10:
assert 'wrong version number' in underlying_error_string
else: # pragma: no cover
assert 'unknown protocol' in underlying_error_string


def test_http_over_https_no_data(mocker):
Expand Down
3 changes: 3 additions & 0 deletions docs/changelog-fragments.d/828.contrib.rst
View file
Open in desktop

@webknjaz webknjaz Jun 23, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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- julianz- Jun 23, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 webknjaz Jun 25, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@webknjaz webknjaz Jun 25, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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- julianz- Jun 26, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 webknjaz Jul 7, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@julianz- I was mainly thinking of trying to avoid relying on the internals instead. I'm not trilled that the tests are fragile due to the fact that OpenSSL works differently under different runtimes. Technically, this is something external to us and so it'd be a good idea to have it abstracted away, but still something will end up having to normalize the error processing.

Anyway.. Let's postpone this for now.

Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
Fixed ``test_https_over_http_error`` failing on Windows with OpenSSL 3.1+,
where the SSL error message is ``wrong version number`` rather than
``record layer failure`` -- by :user:`julianz-`.
Loading