session proxy not working with user/password

All of the below testing was done with Fiddler. User and password proxy auth in Fiddler was enabled the default way by doing Rules->Require Proxy Authentication which requires user be '1' and password be '1'. The code below does not contain the https section of the proxy as it's largely identical.

If a proxy is set on the session without user and password and Fiddler auth is off, Fiddler is used correctly:
`
session.proxies['http'] = 'http://127.0.0.1:8888'.format(proxy_string)
session.request(....)
`

If a proxy is set on the session with user and password, Fiddler returns proxy auth failures:
`
session.proxies['http'] = 'http://1:1@127.0.0.1:8888'.format(proxy_string)
session.request(....)
`

If I do exactly the same thing but send the proxy with the request directly, both cases work.
`
proxies = {}
proxies['http'] = 'http://1:1@127.0.0.1:8888'.format(proxy_string)
session.request(...., proxies=proxies)
`


Thanks for this report @emgerner-msft!

Firstly, can I check: the proxy string in your code doesn't actually separate the port from the host with an `@` symbol. Was that was a typo? If not, that could very really break our parsing of the URL.

Assuming it's a typo, I'd like you to try something for me. Can you reconfigure Fiddler and then print the output of both `requests.utils.should_bypass_proxies(url)` and `requests.utils.get_environ_proxies(url)`, where `url` is the URL you requested when you had this problem.


That was a typo. Sorry about that! Updated the original issue.

I turned on Fiddler with proxy auth and ran the commands as asked with the URL I'm using to make requests. `requests.utils.should_bypass_proxies(uri)` returned `False` and `requests.utils.get_environ_proxies(uri)` returned `{'http': 'http://127.0.0.1:8888', 'https': 'https://127.0.0.1:8888'}`.


Ok, so that's really interesting.

The reason I asked those questions is that we have a known issue at this time around proxies in sessions. Specifically, currently settings set on the Session are considered less authoritative than those in the environment (see #2018). That means that, if you haven't set `session.trust_env = False`, your setting of the proxies on the Session shouldn't have done anything at all. Clearly that's not happening, which is a bit of a concern.

Can I get you to run all four cases (session + no auth, session + auth, request + no auth, request + auth) again, with Fiddler configured to require auth, but each time run it in a brand new Python shell? I want to exclude the effect of connection pooling here, which can play havoc with these kinds of results. 


Read through the bug. I totally agree with the proposed ordering of precedence -- it's actually how I naively assumed it would work. :)

Sounds like to me that bug actually explains things pretty well though. If requests says it should not bypass proxies and the environment correctly gives the Fiddler proxy, that means it's simply using the environment setting instead of the Session proxy. The environment setting doesn't have auth, so it fails. If I set the proxy on the request, it overrides correctly and the auth works. Is this not the correct interpretation of that output and the bug?


I don't think so, not without that final set of tests.  The problem is that the environment proxy strings don't have an auth part, which means we should have failed to auth _ever_ with the session only version. That's why I wanted you to re-test: to understand what the actual behaviour is here. 


We did always fail to proxy with auth on with the proxy set on the session itself. The first case where I thought proxy was working with session was just hitting the environment it looks like -- note for that case Fiddler auth was off. Before you clarified the order of precedence I had misinterpreted this to mean the session proxy just didn't work with auth -- not that it didn't work at all. With auth ON, the only time I got the proxy to work was by setting it directly when making the request `session.request(...., proxies=proxies)`. Your bug explains this perfectly. :) Feel free to close as a duplicate.


Aha, ok, cool. We are scheduling to fix this for 3.0.0. Thanks for the report!