create_ssl_context: raise when verify is a str and cert is provided#990
Conversation
Covers the case where `verify` is a string path and `cert` is a tuple: the cert chain must still be loaded. Before the previous commit, the function returned early and silently dropped the client cert. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Merging this PR will not alter performance
Comparing Footnotes
|
Kludex
left a comment
There was a problem hiding this comment.
I'm not sure this is the right path, I think it's slightly better to raise an error and point the user to pass ctx themselves on verify, since verify as str is deprecated.
The combination of two deprecated parameters silently dropped the client cert chain. Rather than fixing the silent skip, refuse the combination and direct users to build an `ssl.SSLContext` themselves, matching the path the existing deprecation warnings already suggest. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
f5aa1c1 to
ce761fc
Compare
Sure! I've changed the PR to now raise ;-) |
# Conflicts: # src/httpx2/httpx2/_config.py
…text-tuple # Conflicts: # src/httpx2/httpx2/_config.py # tests/httpx2/test_config.py
Kludex
left a comment
There was a problem hiding this comment.
I think this is the solution for the wrong problem.
The problem here is that Client/AsyncClient don't point to the user that cert= is deprecated at that point (so type checkers can point out), and also, that we emit DeprecationWarning - see https://sethmlarson.dev/deprecations-via-warnings-dont-work-for-python-libraries for more details.
All that said, let's merge this for the time being.
Raise when verify is str and we have a cert. This has been deprecated for a while and also it does not work!
Closes #989