David Watson <bai...@users.sourceforge.net> added the comment: > > I don't see how a name resolution API returning non-ASCII bytes > > would indicate an error. > > It's in violation of RFC 952 (slightly relaxed by RFC 1123).
That's bad if it's on the public Internet, but it's not an error. The OS is returning the name by which it knows the host. If you look at POSIX, you'll see that what getaddrinfo() and getnameinfo() look up and return is referred to as a "node name", which can be an address string or a "descriptive name", and that if used with Internet address families, descriptive names "include" host names. It doesn't say that the string can only be an address string or a hostname (RFC 1123 compliant or otherwise). > > But to be more explicit, that's like saying "if it hurts, get > > your sysadmin to reconfigure the company network". > > Which I consider perfectly reasonable. The sysadmin should have > known (and, in practice, *always* knows) not to do that in the first > place (the larger the company, the more cautious the sysadmin). It's not reasonable when addressed to a customer who might go elsewhere. And I still don't see a technical reason for making such a demand. Python 2.x seems to work just fine using 8-bit strings. ---------- title: socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names -> socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9377> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
