classification
Title: Add https?_proxy support to http.client
Type: enhancement Stage: patch review
Components: Library (Lib) Versions: Python 3.6
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: berker.peksag, demian.brecht, martin.panter, orsenthil, r.david.murray
Priority: normal Keywords: patch, patch, patch

Created on 2015-05-13 16:04 by demian.brecht, last changed 2019-02-02 00:17 by demian.brecht.

Pull Requests
URL Status Linked Edit
PR 11729 open demian.brecht, 2019-02-02 00:17
PR 11729 open demian.brecht, 2019-02-02 00:17
PR 11729 open demian.brecht, 2019-02-02 00:17
Messages (5)
msg243101 - (view) Author: Demian Brecht (demian.brecht) * (Python triager) Date: 2015-05-13 16:04
http_proxy and https_proxy are common environment variables used cross platform. Currently, urllib.request has support for it, but http.client does not. It probably should.

If support is added to http.client, the handling of proxy environment variables in urllib.request should be factored out and made to be reliant on the changes in http.client (which shouldn't require any new code, only removal).

Given the common usage of the environment variables (as observed by other utilities such as wget and curl), it seems odd to require a user to know about and use the higher level urllib.request API rather than have support for it baked into the lower level http.client API.
msg252194 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2015-10-03 06:41
I think this would have a serious chance of breaking stuff unless it was only enabled with a new flag or similar. Also, I guess it would probably be limited to Basic authentication.

The wget and curl programs both support different URL protocols, HTTP redirects (if curl --location is enabled), etc. In my mind they operate at a higher level, like urlopen(), and http.client is a more lower-level client. Are there many use cases where you would want proxy support for a HTTP request, but wouldn’t want to use urlopen() or some other high-level library like Requests?
msg252220 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-10-03 15:41
I agree, I think that any proxy support in http.client would need to be opt-in and not on-by-default, exactly because it is a lower level library.
msg252221 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-10-03 15:42
And it should only be added if it actually makes *sense* in the architecture of http.client, which I haven't reviewed with this in mind.
msg252566 - (view) Author: Demian Brecht (demian.brecht) * (Python triager) Date: 2015-10-08 19:37
Yeah, agreed that it should be opt-in, at least until a major release.

I've run into a couple cases where higher level libraries use http.client (or httplib) directly, but don't expose the client directly (not that they should anyways). Because of that, there are higher level libraries that simply /can't/ support http_proxy environment variable because they didn't use a higher level abstraction.

Given http.client /does/ implement everything required to support this, I can't see it impacting the architecture in any negative way.
History
Date User Action Args
2019-02-02 00:17:28demian.brechtsetkeywords: + patch
stage: needs patch -> patch review
pull_requests: + pull_request11619
2019-02-02 00:17:21demian.brechtsetkeywords: + patch
stage: needs patch -> needs patch
pull_requests: + pull_request11618
2019-02-02 00:17:15demian.brechtsetkeywords: + patch
stage: needs patch -> needs patch
pull_requests: + pull_request11617
2015-10-08 19:37:31demian.brechtsetmessages: + msg252566
2015-10-03 15:42:53r.david.murraysetmessages: + msg252221
2015-10-03 15:41:43r.david.murraysetmessages: + msg252220
2015-10-03 06:41:14martin.pantersetnosy: + martin.panter
messages: + msg252194
2015-10-03 04:20:18berker.peksagsetnosy: + berker.peksag
2015-05-13 16:04:25demian.brechtcreate