This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author maxifree
Recipients asvetlov, maxifree, yselivanov
Date 2018-12-20.10:56:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
loop.create_connection doesn't handle ipv6 RFC4007 addresses right since 3.7 

# Set up listener on link-local address fe80::1%lo
sudo ip a add dev lo fe80::1

# 3.6 handles everything fine
socat file:/dev/null tcp6-listen:12345,REUSEADDR &
python3.6 -c 'import asyncio;loop=asyncio.get_event_loop();loop.run_until_complete(loop.create_connection(lambda:asyncio.Protocol(),host="fe80::1%lo",port="12345"))'

# 3.7 and later fails
socat file:/dev/null tcp6-listen:12345,REUSEADDR &
python3.7 -c 'import asyncio;loop=asyncio.get_event_loop();loop.run_until_complete(loop.create_connection(lambda:asyncio.Protocol(),host="fe80::1%lo",port="12345"))'

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.7/asyncio/", line 576, in run_until_complete
    return future.result()
  File "/usr/lib/python3.7/asyncio/", line 951, in create_connection
    raise exceptions[0]
  File "/usr/lib/python3.7/asyncio/", line 938, in create_connection
    await self.sock_connect(sock, address)
  File "/usr/lib/python3.7/asyncio/", line 475, in sock_connect
    return await fut
  File "/usr/lib/python3.7/asyncio/", line 480, in _sock_connect
OSError: [Errno 22] Invalid argument


Upon asyncio.base_events.create_connection _ensure_resolved is called twice, first time here:
then here through sock_connect:

_ensure_resolved calls getaddrinfo, but in 3.7 implementation changed:

% python3.6 -c 'import socket;print(socket.getaddrinfo("fe80::1%lo",12345)[0][4])'
('fe80::1%lo', 12345, 0, 1)

% python3.7 -c 'import socket;print(socket.getaddrinfo("fe80::1%lo",12345)[0][4])'
('fe80::1', 12345, 0, 1)

_ensure_connect only considers host and port parts of the address tuple:

In case of 3.7 first call to _ensure_resolved returns
('fe80::1', 12345, 0, 1)
then second call returns
('fe80::1', 12345, 0, 0)
Notice that scope is now completely lost and is set to 0, thus actual call to socket.connect is wrong

In case of 3.6 both first and second call to _ensure_resolved return
('fe80::1%lo', 12345, 0, 1)
because in 3.6 case scope info is preserved in address and second call can derive correct address tuple
Date User Action Args
2018-12-20 10:56:50maxifreesetrecipients: + maxifree, asvetlov, yselivanov
2018-12-20 10:56:50maxifreesetmessageid: <>
2018-12-20 10:56:50maxifreelinkissue35545 messages
2018-12-20 10:56:50maxifreecreate