URL proxy auth with empty passwords doesn't emit auth header.

I'm using a proxy that requires authentication to send request that receives 302 response with Location header. I would like python.requests to follow this redirect and make request via proxy with specified credentials. But it seems like this doesn't happen, if I provide credentials in HTTPProxyAuth they will work ok for 200 responses but will fail for 302. See below code sample:

```python

import requests
from requests.auth import HTTPProxyAuth

sess = requests.Session()
url1 = 'http://httpbin.org/'
url2 = 'http://httpbin.org/redirect/2'
auth = HTTPProxyAuth('frank', 'hunter2')
proxies = {
    "http": "http://localhost:9000"
}
response1 = sess.get(url1, proxies=proxies, auth=auth)
response1.raise_for_status()
response2 = sess.get(url2, proxies=proxies, auth=auth)
response2.raise_for_status()
```
Now launch MITM proxy on localhost

```
> mitmproxy -p 9000 --singleuser=frank:hunter2
```

This fails with 407 for me, and proxy logs only two requests

```
    response2.raise_for_status()
  File "----------", line 862, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 407 Client Error: Proxy Authentication Required for url: http://httpbin.org/relative-redirect/1
```

```
>> GET http://httpbin.org/
       ← 200 text/html 11.87kB 3.57MB/s
   GET http://httpbin.org/redirect/2
       ← 302 text/html 247B 76.59kB/s

```
it does not log request to `Location`. 

I see that putting credentials in proxies dictionary somehow fixes this issue when I use MITM proxy but it doesn't fix it for my production proxy (can't share code or proxy details here, need to check closer why it doesn't work for my proxy). I guess some details in setup of proxies might vary.

Is this a bug? I see some issues for proxy auth but they are mostly about HTTPS, not sure if someone reported this thing I describe here. Should this be fixed?

EDIT:

It looks like this always fails if proxy password is empty string.

change auth to 

```python
auth = HTTPProxyAuth('frank', '')

proxies = {
    "http": "http://frank:@localhost:9000"
}
```

will now always fail on redirect.

```python
auth = HTTPProxyAuth('frank', 'hunter2')
proxies = {
    "http": "http://frank:hunter2@localhost:9000"
}
```
works fine on redirects, but seems somewhat duplicated.

I noticed this on Ubuntu 14.04, requests 2.11.1, python 2.7.6, mitmproxy 0.10.1

Ok, let's tightly restrict the scope of this bug.

Firstly, HTTPProxyAuth is a backward compatibility auth. It does not integrate well with httplib's handling of proxies, especially for CONNECT HTTPS proxying. We don't want you to use it. Please put the auth into the proxy URL, as you have discovered.

So the second case is that you seem to be suggesting that if we proxy auth using an empty password, that gets stripped on redirects? If you remote the HTTPProxyAuth and just leave the auth in the proxy URL, do you still lose the auth on the redirect?


Aha, ok, so it looks like if there is no password we don't emit auth _at all_ if it comes from the URL. This is presumably a URL parsing issue. Out of interest, why on earth do you have a proxy that requires authorization but allows an _empty_ password field?


>  Out of interest, why on earth do you have a proxy that requires authorization but allows an empty password field?

proxy just uses apikey as username so that auth is: `"bunch_of_illegible_tokens_some_sha226_or_something:<empty string>"`. I was suprised by this too, but proxy developer told me: "this becomes common convention for proxies"


> Firstly, HTTPProxyAuth is a backward compatibility auth. It does not integrate well with httplib's handling of proxies, especially for CONNECT HTTPS proxying. We don't want you to use it. Please put the auth into the proxy URL, as you have discovered.

should we add some deprecation warning for that? I can add it too, sounds like patch with 'easy' tag.


That is totally bizarre. Utterly, totally bizarre. But ok. =P

I'm happy for us to add a deprecation warning. And we clearly have a bug around the auth-in-url stuff. We should fix that. =D


This issue looks easily fixed too: the `proxy_headers` method on the HTTPAdapter requires truthy values for both `username` and `password`. I recommend that that be changed to only require a truthy value for `username`, along with a test. Would you like to make that change @pawelmhm?


sure will send pr