Proxies that depend on the URL

Currently the proxies dictionary supports only schemes as keys.  In networks with multiple proxies, this may not be sufficient for picking the correct proxy.  I propose that we allow scheme+hostname, hostname, and scheme (in that order) as keys, searched in that order.  Changing this line, https://github.com/kennethreitz/requests/blob/2440b6f089f4c53e96cd2ece80e92774b72ed243/requests/adapters.py#L242, could search first for the scheme+hostname, then the hostname, then the scheme.

I'm not sure of all the ramifications of this in other parts of the codebase, but this would greatly help when we have a more complicated proxy setup than one just relying on schemes.


This might be a good idea, but I wonder how it plays out with the other proxy variables. This needs to be carefully considered. 

How is this handled by other tools? `apt-get`, for instance?


Good idea to look at apt.  According to http://manpages.ubuntu.com/manpages/utopic/man5/apt.conf.5.html, apt supports both per-host proxies and a way to call out to an arbitrary external program to get the proxy.  The calling out to an external function is like the PAC configuration that is pretty widespread.  Relevant parts of that manpage are:

```
       http::Proxy sets the default proxy to use for HTTP URIs. It is in
       the standard form of http://[[user][:pass]@]host[:port]/. Per host
       proxies can also be specified by using the form http::Proxy::<host>
       with the special keyword DIRECT meaning to use no proxies. If no
       one of the above settings is specified, http_proxy environment
       variable will be used.
```

and 

```
       Acquire::http::Proxy-Auto-Detect can be used to specify an external
       command to discover the http proxy to use. Apt expects the command
       to output the proxy on stdout in the style http://proxy:port/. This
       will override the generic Acquire::http::Proxy but not any specific
       host proxy configuration set via Acquire::http::Proxy::$HOST. See
       the squid-deb-proxy-client(1) package for an example implementation
       that uses avahi. This option takes precedence over the legacy
       option name ProxyAutoDetect.
```

We could support calling out to an external program (obviously the most flexible), but that would be a much bigger change.  The change I'm proposing would be sufficient for my needs.

What can we do to continue to move the discussion forward?


One downside is that if you have a host named 'http', then the proxy dictionary gets confused between whether that is a host or a scheme.  I'd be happy also if we just resolved scheme+'://'+hostname first, then scheme.  That is forward compatible with the original proposal, and avoids the ambiguity when a hostname is the same as a scheme.

So, in summary, I'm proposing that the proxies dictionary be something of the form: `{'<scheme>://<hostname>': proxy, '<scheme>': proxy}`, and that a host-specific proxy takes precedence over a scheme proxy.


Ok, I think that approach sounds reasonable to me: I think this feature request requires relatively little code and enables a fairly useful use-case. Thoughts from the other maintainers? /cc @kennethreitz @sigmavirus24


Ping about this.  Is there anything I can do to help the discussion along?


Sadly @jasongrout the project has a low communication bandwidth at the moment: I'm moving flat and so am without fixed-line internet, and the other two maintainers are taking well-needed rests. This hasn't been lost, I promise!


Thanks!  I'll continue with my patched version for now, and ping again in a bit.  Good luck on your move, and thanks again for all of your efforts!


I opened a PR implementing this solution at https://github.com/kennethreitz/requests/pull/2741