Martin Panter added the comment: I closed Issue 18543 as a duplicate, which points out this also affects Python 2.7.9+, and can also be triggered by setting the “context” parameter.
Overall, I am not comfortable with the complication and hacks in the current patch. Maybe it would be simpler to not fix the bug, and just document that you cannot use the SSL context parameters with a custom opener. If necessary, we could add a new API to pass the context to the handler properly, as suggested by Benjamin in <https://bugs.python.org/issue23166#msg233484>, but that might have to be in 3.6+ only. Some specific comments on the patch: The url[:5] check should probably check for a colon as well. What’s the problem with multiple HTTPS handlers? Is it a side effect of your patch, or did it already exist? Is it only a problem for urlopen(), or also for calling open() directly? You can use any() instead of building a list and testing if it is empty. I think you can handle https: URLs without defining https_open(), for instance I have a handler that defines default_open() and checks the request manually. Does your patch account for that? The patch seems to modify the default installed opener with the supplied SSL parameters. Also I wonder if it would break any multithreaded usage that currently works. It would be good to have test cases integrated into the existing suite. ---------- nosy: +martin.panter stage: -> patch review title: urllib.parse.urlopen shouldn't ignore installed opener when called with any ca* argument -> urllib.parse.urlopen shouldn't ignore installed opener when called with any SSL argument versions: +Python 2.7 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18543> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
