proxies missing [ipv6] address support

For an IPv6 proxy address then proxies-dict is not working en ends with temporary nameresolving problems. Change of the addess to a name (name added with ipv6 address in /etc/hosts) the proxies-dict is working.
For IPv4 an address is working

```
proxies={"https":"http:[<ipv6:address>]:<portnumber>"} fails
proxies={"https":"http:[<proxyname>:<portnumber>"} succeeds (/etc/hosts entry: "<ipv6:address> <proxyname>"] 
proxies={"https":"http:[<ipv4.address>:<portnumber>"} succeeds
```


What does _fails_ mean, please? Can you provide a clearer explanation of what you expect to happen and what is actually happening?


Hello, 
I'm sorry for not being clear in this call. 
I use the proxies dict to access the internet via a proxy server.
1 Using an ipv4 address passes the proxy
2 Using a name resolved to either an ipv4 or ipv6 address passes the proxy
3 Using an ipv6 address enclosed in [ ] it fails with a temporary resolving error and is not passing the proxy.
It seems that an ipv6 address is not being recognized as an ip address and therefore is used as a name to be resolved. 
Kind regards, Luitzen  woensdag, 24 augustus 2016, 04:34PM +02:00 van Cory Benfield  notifications@github.com :

> What does  fails mean, please? Can you provide a clearer explanation of what you expect to happen and what is actually happening?
> —
> You are receiving this because you authored the thread.
> Reply to this email directly,  view it on GitHub , or  mute the thread .


When you say it fails with a temporary resolving error, do you get a traceback? If you do, can you provide it please?


@lvg01 just a friendly reminder that we still need some information from you here. Thanks in advance!


At first, excuses for my late response..

With the proxies={"https":"http://[abcd:0123:dcba:3210::1]:3128"} the command fails with following traceback:

```
Traceback (most recent call last):
  File "/usr/local/sendsms.py", line 96, in <module>
    r = requests.post(gwURL, data=xmltree, headers=headers, proxies=proxyDict)
  File "/usr/lib/python2.7/site-packages/requests/api.py", line 108, in post
    return request('post', url, data=data, json=json, **kwargs)
  File "/usr/lib/python2.7/site-packages/requests/api.py", line 50, in request
    response = session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 464, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 576, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python2.7/site-packages/requests/adapters.py", line 424, in send
    raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='url.org', port=443): Max retries exceeded with url: /smssgateway/cm/gateway.ashx (Caused by ProxyError('Cannot connect to proxy.', gaierror(-3, 'Temporary failure in name resolution')))
```

With /etc/hosts line 'abcd:0123:dcba:3210::1 proxy' and proxies={"https":"http://proxy:3128"} the command succeeds.


Yup, this looks like an error in parsing URLs. @sigmavirus24, you're the resident expert here: any thoughts?


@Lukasa I don't see the problem parsing the URL. 

```
Caused by ProxyError('Cannot connect to proxy.', gaierror(-3, 'Temporary failure in name resolution'))
```

Seems like that _might_ be the problem based on that message but I'm having trouble figuring out why. We [create a ProxyManager](https://github.com/kennethreitz/requests/blob/5259b374512ec4e47785f5004ec6ad30dafe906f/requests/adapters.py#L188) from urllib3 which parses the URL using `parse_url` from it's url utility module. This parses the example without issue and has always handled IPv6 addresses correctly.

If we look at the ProxyManager it has different logic for requests to an [https url versus an http url](https://github.com/kennethreitz/requests/blob/05d90b9379f57ee5f5d0beb268c495793fb5b2d7/requests/packages/urllib3/poolmanager.py#L331). 

I'm failing to see where the URL parsing would fail and why an IPv6 literal address would cause a name resolution failure.


@lvg01 Can you confirm that this works for me, please?

``` python
import socket
socket.getaddrinfo('[abcd:0123:dcba:3210::1]', 80)
```


@Lukasa it should be 

``` py
import socket
socket.getaddrinfo('[abcd:0123:dcba:3210::1]', 3128)
```

As that's the port specified in the proxy url that @lvg01 is showing us


sorry for the late response, I was busy for some other things...

The test gives the same error:

> > > import socket
> > > socket.getaddrinfo('[abcd:0123:dcba:3210::1]',80)
> > > Traceback (most recent call last):
> > >    File "<stdin>", line 1, in <module>
> > > socket.gaierror: [Errno -3] Temporary failure in name resolution

On 06-09-16 13:34, Cory Benfield wrote:

> import  socket
> socket.getaddrinfo('


as for port 3128, the same:

> > > socket.getaddrinfo('[abcd:0123:dcba:3210::1]',3128)
> > > Traceback (most recent call last):
> > >    File "<stdin>", line 1, in <module>
> > > socket.gaierror: [Errno -3] Temporary failure in name resolution

On 06-09-16 14:38, Ian Cordasco wrote:

> @Lukasa https://github.com/Lukasa it should be
> 
> import  socket
> socket.getaddrinfo('[abcd:0123:dcba:3210::1]',3128)
> 
> As that's the port specified in the proxy url that @lvg01 
> https://github.com/lvg01 is showing us
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> https://github.com/kennethreitz/requests/issues/3534#issuecomment-244936907, 
> or mute the thread 
> https://github.com/notifications/unsubscribe-auth/APqn3sQEPsDAyL0KKslJrvy1Vc1lJvUwks5qnV66gaJpZM4Jr16P.


@lvg01 And what results do you get without the square brackets?


Hé, thats a good suggestion, then the test-code works!

So there is a parsing problem... Becaus in de proxies dict the ip 
address is surrounded by square brackets to seperate the ipv6 address 
with the tcp port (normal convention). The square brackets have to be 
stripped somewhere in the code OR the library should be able to read 
square bracket enclosed ipv6 addresses...

On 07-09-16 09:20, Cory Benfield wrote:

> @lvg01 https://github.com/lvg01 And what results do you get without 
> the square brackets?
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> https://github.com/kennethreitz/requests/issues/3534#issuecomment-245196498, 
> or mute the thread 
> https://github.com/notifications/unsubscribe-auth/APqn3rUJ7CGgmbzHaY4zyhwxadrL8tVEks5qnmXagaJpZM4Jr16P.


So I don't think there's strictly a _parsing_ problem so much as there's a usage problem. Somewhere in urllib3/requests we are failing to strip the square brackets from the IPv6 address before we do a lookup on it.


OK, I understand. When separating the IP from the PORT the IP has to 
stripped before using the libraries beneath it.

On 07-09-16 10:42, Cory Benfield wrote:

> So I don't think there's strictly a /parsing/ problem so much as 
> there's a usage problem. Somewhere in urllib3/requests we are failing 
> to strip the square brackets from the IPv6 address before we do a 
> lookup on it.
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> https://github.com/kennethreitz/requests/issues/3534#issuecomment-245214619, 
> or mute the thread 
> https://github.com/notifications/unsubscribe-auth/APqn3vq8B2cvKtBuIsp1rlA2Ns4MWlMSks5qnnj6gaJpZM4Jr16P.


I think this is a problem in urllib3's Proxy|Pool Manager.


I'm fairly confident we've fixed this in urllib3. I vaguely remember the fix. As such, I'm going to close this. If I'm mistaken, I'll happily reopen it just let me know.