You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee='https://github.com/orsenthil'closed_at=Nonecreated_at=<Date2010-03-07.11:22:53.071>labels= ['type-feature', 'library']
title='urllib proxy interface is too limited'updated_at=<Date2013-10-20.18:22:13.381>user='https://github.com/ronaldoussoren'
The proxy support code in urllib is imho too specific and cannot easily support dynamic proxy configuration using a proxy.pac file.
That is, the code assumes that there is at most one proxy per protocol, while this is not quite true in practice. A proxy.pac can refer different URLs to different proxies (or exclude some from proxying).
This could be solved by adding a new proxy hook to urllib, something like:
defgetproxies_for_url(url) -> [info, ...]
That is, the argument is the string for an URL, the result is a list of proxies that can be used to fetch the URL.
This hook would allow us to provide a hook on OSX that enables python scripts to use the system proxy settings, even when those are complex (such as by using proxy autoconfiguration).
I like the idea of having the proxy handler expanded. In fact I suggest to base the idea on libproxy ( http://code.google.com/p/libproxy ) which is available on Linux / openSolaris / Windows and Mac (currently).
Libproxy queries the correct settings to be used from KDE and gnome, depending on the currently running session. A fallback is of course env.
the API of libproxy is very simple and python bindings are available.
If we link against this maintained library and pass the proxy handling configuration to be handled by the library, that would be a better idea than re-implementing parts of this library in python.
Activity
ronaldoussoren commentedon Mar 7, 2010
The proxy support code in urllib is imho too specific and cannot easily support dynamic proxy configuration using a proxy.pac file.
That is, the code assumes that there is at most one proxy per protocol, while this is not quite true in practice. A proxy.pac can refer different URLs to different proxies (or exclude some from proxying).
This could be solved by adding a new proxy hook to urllib, something like:
That is, the argument is the string for an URL, the result is a list of proxies that can be used to fetch the URL.
This hook would allow us to provide a hook on OSX that enables python scripts to use the system proxy settings, even when those are complex (such as by using proxy autoconfiguration).
DominiqueLeuenberger commentedon Mar 9, 2010
I like the idea of having the proxy handler expanded. In fact I suggest to base the idea on libproxy ( http://code.google.com/p/libproxy ) which is available on Linux / openSolaris / Windows and Mac (currently).
Libproxy queries the correct settings to be used from KDE and gnome, depending on the currently running session. A fallback is of course env.
the API of libproxy is very simple and python bindings are available.
orsenthil commentedon Nov 8, 2026
Current libproxy reference - https://github.com/libproxy/libproxy
If we link against this maintained library and pass the proxy handling configuration to be handled by the library, that would be a better idea than re-implementing parts of this library in python.
orsenthil commentedon Nov 9, 2026
This request will be best be handled by https://pypac.readthedocs.io/en/latest/
If we document how to use
urllib.requestwith pypac, it will be sufficient to address and close this ticket, in my opinion.orsenthil commentedon Nov 10, 2026
Here is a PR that explains how urllib interface can be used along with pypac pypi package - #161729
I had a driver function to test this - https://github.com/orsenthil/urllib-pac-recipe and verify that suggested approach in the documentation will work.