[issue15769] urllib.request.urlopen with cafile or capath set overrides any previous Handlers

2017-01-26 Thread Martin Panter
Martin Panter added the comment: Nothing has been fixed; I don’t see any evidence that this is “out of date”. Here is a more complete test: import urllib.request opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor()) urllib.request.install_opener(opener) request =

[issue15769] urllib.request.urlopen with cafile or capath set overrides any previous Handlers

2016-09-08 Thread Christian Heimes
Christian Heimes added the comment: The ticket hasn't moved in about four years. Does the issue still persist? -- nosy: +christian.heimes resolution: -> out of date stage: needs patch -> patch review status: open -> pending versions: +Python 3.6, Python 3.7 -Python 3.2, Python 3.3,

[issue15769] urllib.request.urlopen with cafile or capath set overrides any previous Handlers

2012-08-23 Thread Senthil Kumaran
Senthil Kumaran added the comment: I could verify this bug and also looks like a tricky one. Because when we are sending the cacert (the second time), we create a new HTTPSHandler and then build the opener again using that handler. I thought, we can use the existing opener object itself like

[issue15769] urllib.request.urlopen with cafile or capath set overrides any previous Handlers

2012-08-23 Thread Brian Turek
Brian Turek added the comment: I was actually going to come up with a patch that does the same thing orsenthil mentioned until I too was stymied by the use of bisect.insort Does anyone know why bisect.insort was used instead of just list.append? I don't see an obvious reason so I think just

[issue15769] urllib.request.urlopen with cafile or capath set overrides any previous Handlers

2012-08-23 Thread R. David Murray
R. David Murray added the comment: It has been a while since I looked at the code, but if I remember correctly there is a (somewhat non-obvious) mechanism for assigning priority to handlers, so that you can control the order of application. If I'm right the insort is about that priority, and

[issue15769] urllib.request.urlopen with cafile or capath set overrides any previous Handlers

2012-08-23 Thread Antoine Pitrou
Antoine Pitrou added the comment: -opener = build_opener(https_handler) +if _opener is None: +opener = build_opener(https_handler) +else: +opener = _opener +opener.add_handler(https_handler) Well, isn't it a bad idea to mutate the

[issue15769] urllib.request.urlopen with cafile or capath set overrides any previous Handlers

2012-08-23 Thread Brian Turek
Brian Turek added the comment: So I'm not saying the attached patch is the *best* solution but it doesn't mangle the existing urllib.request._opener too much. -- keywords: +patch Added file: http://bugs.python.org/file26977/request.patch ___ Python

[issue15769] urllib.request.urlopen with cafile or capath set overrides any previous Handlers

2012-08-22 Thread Brian Turek
New submission from Brian Turek: Using the code snippet below: cj = http.cookiejar.CookieJar() opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor()) urllib.request.install_opener(opener) request = urllib.request.Request(url, data, headers) # url is https://something sock =

[issue15769] urllib.request.urlopen with cafile or capath set overrides any previous Handlers

2012-08-22 Thread R. David Murray
R. David Murray added the comment: I thought that was an issue when I was looking at the code the other day, but I didn't get around to testing it. Thanks for the report. -- nosy: +orsenthil, pitrou, r.david.murray stage: - needs patch ___ Python