Kurt Rose added the comment:
I think this may in fact be a bug. There are other places in the socket module
where port is checked, create_connection() just seems to have been missed.
create_connection() and socket.connect() have different behavior:
socket.create_connection( ('google.com',
Kurt Rose added the comment:
I was incorrect -- the result of getsockname() appears to be some garbage port:
socket.create_connection( ('google.com', 2**16 + 80) ).getsockname()
('10.225.89.86', 56446)
socket.create_connection( ('google.com', 2**16 + 80) ).getsockname()
('10.225.89.86',
Kurt Rose added the comment:
Sorry, dumb mistake on my part. I should have been calling getpeername(), not
getsockname()
In that case the result is 80:
socket.create_connection( ('google.com', 2**16 + 80) ).getpeername()
('74.125.239.41', 80)
The random ports were the client-side ephemeral
New submission from Kurt Rose:
This appears to affect all versions of Python. In a behavior inherited from C,
TCP ports that are 2 bytes are silently truncated.
Here is a simple reproduction:
socket.create_connection( ('google.com', 2**16 + 80) )
socket.socket object, fd=408, family=2,
R. David Murray added the comment:
You pegged it when you said the behavior is inherited from C. Technically this
isn't a bug in Python, since the socket module is a set of (mostly) thin
wrappers around the C.
Enhancing CPython to do the check is not a bad suggestion, especially since it
Kurt Rose added the comment:
Totally agree this needs to be managed carefully. My goal here was just to
raise awareness and see if there is consensus that the behavior should be
changed.
I came across this because an upstream process had a bug which led to
impossible TCP ports being
