classification
Title: test suite intentionally avoids referring to localhost, destroying abstraction away from IPv6 vs IPv4
Type: Stage:
Components: Tests Versions: Python 3.7, Python 3.6, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: gregory.p.smith Nosy List: brian.curtin, gregory.p.smith, paul.moore, pitrou, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2017-02-24 01:34 by gregory.p.smith, last changed 2017-03-16 00:38 by gregory.p.smith.

Messages (6)
msg288498 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2017-02-24 01:34
I am working on fixing our test suite to run on IPv6 only hosts (which are becoming a reality).  Many failures today occur because of hard coded 127.0.0.1 values.

This is wrong.  We should refer to "localhost"

The "solution" to https://bugs.python.org/issue18792 moved us backwards towards hard coding IP version type specific addresses claiming that windows cannot handle resolving localhost reliably.

On any windows system where that is the case we should declare the system broken and simply not run any networking related tests.
msg288628 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-02-27 10:13
I'm not sure how much of the original analysis was right.  I've just fired up a network-less Windows VM and 'localhost' seems to resolve just fine:

>>> socket.gethostbyname('localhost')
'127.0.0.1'
>>> socket.getaddrinfo('localhost', 80, socket.AF_UNSPEC, socket.SOCK_STREAM)

[(<AddressFamily.AF_INET6: 23>,
  <SocketKind.SOCK_STREAM: 1>,
  0,
  '',
  ('::1', 80, 0, 0)),
 (<AddressFamily.AF_INET: 2>,
  <SocketKind.SOCK_STREAM: 1>,
  0,
  '',
  ('127.0.0.1', 80))]


But we should defer to our Windows experts on this.

(also, perhaps we should simply mandate that buildbots have at least basic DNS functionality. This would lighten the maintenance load on the test suite slightly.)
msg288638 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2017-02-27 12:11
I have a vague recollection of once working on a (Windows) system that mis-resolved localhost. But it was a long time ago, and I'm 100% OK with calling such a system broken.

+1 on using localhost
msg288640 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2017-02-27 13:07
I echo Paul. I think the last time I would have seen a problem was on Windows 2000, which is unsupported per PEP-11.

+1 to using localhost
msg288652 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-02-27 17:31
As far as I recall, there's a hosts file that resolves localhost to 127.0.0.1 on Windows, which means a user could break their own configuration if they so desired. Definitely on all supported versions we should be able to assume localhost can be resolved.

I haven't checked out how it deals with IPv6, but presumably there's a priority or another hosts file that will cover it.
msg288682 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2017-02-27 23:46
great! that makes me feel much less bad about fixing this in the way i desire. :)
History
Date User Action Args
2017-03-16 00:38:26gregory.p.smithsetassignee: gregory.p.smith
2017-02-27 23:46:13gregory.p.smithsetmessages: + msg288682
2017-02-27 17:31:36steve.dowersetmessages: + msg288652
2017-02-27 13:07:42brian.curtinsetnosy: + brian.curtin
messages: + msg288640
2017-02-27 12:11:25paul.mooresetmessages: + msg288638
2017-02-27 10:13:57pitrousetnosy: + paul.moore, pitrou, tim.golden, zach.ware, steve.dower
messages: + msg288628
2017-02-24 01:34:57gregory.p.smithcreate