Message168932
| Author |
orsenthil |
| Recipients |
caligatio, orsenthil, pitrou, r.david.murray |
| Date |
2012年08月23日.09:52:57 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1345715579.7.0.0417575692103.issue15769@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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 this -
- opener = build_opener(https_handler)
+ if _opener is None:
+ opener = build_opener(https_handler)
+ else:
+ opener = _opener
+ opener.add_handler(https_handler)
But even then the problem is, the existing default HTTPSHandler will be invoked before the newly added one, as add_handler does a bisect.insert to add new handlers.
Thinking what's the best way to insert this new updated HTTPS handler in front of the existing ones (without resorting to any hacks). |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2012年08月23日 09:52:59 | orsenthil | set | recipients:
+ orsenthil, pitrou, r.david.murray, caligatio |
| 2012年08月23日 09:52:59 | orsenthil | set | messageid: <1345715579.7.0.0417575692103.issue15769@psf.upfronthosting.co.za> |
| 2012年08月23日 09:52:59 | orsenthil | link | issue15769 messages |
| 2012年08月23日 09:52:58 | orsenthil | create |
|