-
-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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.
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
monkey patching of urllib3 #5238
Comments
I have this issue too, thank you for the workaround! And a few lines of code that reproduce the error, uncomment to enable workaround:
|
This was resolved in #5443 and Requests no longer attempts this unless ssl isn't available through Python. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I'm using urllib3 and recently ran into an issue where my library would fail if pyopenssl was installed and requests was imported (by some other library).
This error happens when connecting to any https domain and is likely due to some mis-configured certs (though it happened on two unrelated linux machines I ran it on), but this behavior only occurs when pyopenssl is installed and requests is imported, so it's hard to test for something like this.
It looks like requests monkey patches urllib3:
requests/requests/__init__.py
Line 93 in 3e7d0a8
Now that I know this, I could have my library require requests, import requests, and then run
urllib3.contrib.pyopenssl.extract_from_urllib3()
to reverse-monkey-patch urllib3, but this seems roundabout.Is there any reason this is enabled for versions of python > 3.2? I think a decent fix to me is that the monkey patching code is only run on the versions of python that require it.
The text was updated successfully, but these errors were encountered: