This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients BreamoreBoy, b.a.scott, dieresys, martin.panter, mbeachy, orsenthil, ronaldoussoren, tsujikawa, vzafzal
Date 2015-05-31.03:57:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I believe this also affects Python 3; see Issue 24333.

I think making the CONNECT response object available to the caller is the right general approach. But I really dislike raising an exception that holds a socket connection to be closed. (I know this is already done with urllib.error.HTTPError; let’s not repeat this in the “http.client” module!)

Ideally, at the “http.client” level I would prefer to avoid all the special set_tunnel() calls, and use the usual request() and getresponse() API to make the CONNECT request. This way the response status and header fields would be available just like any other response. For this approach to work, we would probably need to add a new HTTPConnection.detach() method that released the original socket reader and writer, and add a way to create a new HTTPConnection instance using these socket objects. This enhancement probably wouldn’t be appropriate for Python 2 or a bug fix release. But it seems the cleanest approach to me, and may also allow using HTTPConnection with the Upgrade header (e.g. for opportunistic encryption, HTTP 2, Web etc), and proxying non-HTTP connections, as bonuses.

A less revolutionary approach might be to add a HTTPSConnection.tunnel() method, that always returns the proxy’s response, but only does the SSL wrapping for a successful response.
Date User Action Args
2015-05-31 03:57:45martin.pantersetrecipients: + martin.panter, ronaldoussoren, orsenthil, mbeachy, dieresys, tsujikawa, BreamoreBoy, b.a.scott, vzafzal
2015-05-31 03:57:45martin.pantersetmessageid: <>
2015-05-31 03:57:45martin.panterlinkissue7291 messages
2015-05-31 03:57:43martin.pantercreate