HTTPS proxy fails with requests.

Using `requests` with an HTTPS proxy (Node.js with `https` to receive incoming requests and `http-proxy` to tunnel) always results in:

```
requests.exceptions.ConnectionError: ('Connection aborted.', BadStatusLine("''",))
```

The Node.js proxy server intentionally returns 401 on all requests for testing purposes. If 401 won't work, there's no reason to add the rest of the functionality.

Using httplib (correct response):
```
>>> import httplib
>>> conn = httplib.HTTPSConnection('censored-proxy-domain.com', 8081)
>>> conn.request('HEAD', 'https://www.google.com')
>>> res = conn.getresponse()
>>> res.status
401
```

Using urllib.urlopen (correct response):
```
>>> urllib.urlopen('https://www.google.com', proxies=proxies)
...
IOError: ('http error', 401, 'Unauthorized', <httplib.HTTPMessage instance at 0x032A7AA8>)
```

But using requests:
```
r = requests.get('https://www.google.com', proxies=proxies)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\site-packages\requests\api.py", line 72, in get
    return request('get', url, params=params, **kwargs)
  File "C:\Python27\lib\site-packages\requests\api.py", line 58, in request
    return session.request(method=method, url=url, **kwargs)
  File "C:\Python27\lib\site-packages\requests\sessions.py", line 508, in request
    resp = self.send(prep, **send_kwargs)
  File "C:\Python27\lib\site-packages\requests\sessions.py", line 618, in send
    r = adapter.send(request, **kwargs)
  File "C:\Python27\lib\site-packages\requests\adapters.py", line 490, in send
    raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', BadStatusLine("''",))
```

The `requests` request also never gets received or handled/logged in the proxy server. Any other library or 3rd party tool has worked (test in browser, Proxifier, ProxyCap).

## Expected Result

I expect `requests` to return a similar result to any other library.

## Actual Result

Logs above.

## Reproduction Steps

```python
import requests

```

## System Information

    $ python -m requests.help

```
{
  "chardet": {
    "version": "3.0.4"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": ""
  },
  "implementation": {
    "name": "CPython",
    "version": "2.7.12"
  },
  "platform": {
    "release": "10",
    "system": "Windows"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.18.3"
  },
  "system_ssl": {
    "version": "1000208f"
  },
  "urllib3": {
    "version": "1.22"
  },
  "using_pyopenssl": false
}
```

This command is only available on Requests v2.16.4 and greater. Otherwise,
please provide some basic information about your system (Python version,
operating system, &c).

Can you show me the contents of the `proxies` dict please?

@Lukasa Tested with these:
```
proxies = {'http': 'http://censored-proxy-domain.com:8080', 'https': 'https://censored-proxy-domain.com:8081'}
proxies = {'http': 'https://censored-proxy-domain.com:8081', 'https': 'https://censored-proxy-domain.com:8081'}
proxies = {'https': 'https://censored-proxy-domain.com:8081'}
proxies = {'http': 'censored-proxy-domain.com:8080', 'https': 'censored-proxy-domain.com:8081'}
```
The first one was used with urllib, the others were just random tests to make sure I didn't miss any test case. The domain resolves to `127.0.0.1` via Windows' hosts file (done to use the real domain's Let's Encrypt SSL certificate to have a valid one).

Does `requests` have a problem with the hosts file?

Can you try:

```
proxies = {'http': 'http://censored-proxy-domain.com:8080', 'https': 'https://censored-proxy-domain.com:8081'}
```

Requests doesn't do what you'd expect when the scheme of the proxy URL is `https`.

Requests does not have a problem with the hosts file.

@Lukasa That's the same as my first example.

@sebastienvercammen Ah, sorry, I meant this:

```
proxies = {'http': 'http://censored-proxy-domain.com:8080', 'https': 'http://censored-proxy-domain.com:8081'}
```

Forgot to actually make the edit.

@Lukasa Tried it, same result:
```
>>> proxies
{'http': 'http://censored-proxy-domain.com:8080', 'https': 'http://censored-proxy-domain.com:8081'}
>>> r = requests.get('https://www.google.com', proxies=proxies)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\site-packages\requests\api.py", line 72, in get
    return request('get', url, params=params, **kwargs)
  File "C:\Python27\lib\site-packages\requests\api.py", line 58, in request
    return session.request(method=method, url=url, **kwargs)
  File "C:\Python27\lib\site-packages\requests\sessions.py", line 508, in request
    resp = self.send(prep, **send_kwargs)
  File "C:\Python27\lib\site-packages\requests\sessions.py", line 618, in send
    r = adapter.send(request, **kwargs)
  File "C:\Python27\lib\site-packages\requests\adapters.py", line 490, in send
    raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', BadStatusLine("''",))
```
Same when `http://censored-proxy-domain.com:8080` is used for both `http` and `https` in the proxies dict.

Hrm, can you try using wire shark to compare Requests to urllib? My suspicion is that your proxy server doesn't like our HTTP/1.0 HEAD request.

@Lukasa Thank you, your suggestion to check Wireshark helped me to notice that `requests` first sends a `CONNECT` request, which led me to find that Node.js' HTTP and HTTPS servers have something specific about them:

https://nodejs.org/api/http.html#http_event_connect_1

> Emitted each time a client requests an HTTP CONNECT method. **If this event is not listened for, then clients requesting a CONNECT method will have their connections closed.**

Perhaps it could help to let `requests` show a more helpful exception message?

Requests is kind of doing the best it can: its expecting a response and not getting one before EOF. Sadly that error is emitted by our parser, which is httplib, so until and unless we swap parser it's hard for us to get a better error here. 🙁

@Lukasa Perfectly understandable. Closing this issue because it was resolved.