Marc-Andre Lemburg <m...@egenix.com> added the comment: Martin v. Löwis wrote: > > Martin v. Löwis <mar...@v.loewis.de> added the comment: > >> Sorry, I didn't mean how Windows constructs the result for the >> "A" interface - I was talking about Python code being able to map >> the result from the Unicode interface to the form used in the >> protocol (e.g. DNS). I believe the proposal is to use the DNS >> name > > I disagree with the proposal - it should return whatever > name gethostname from winsock.dll returns (which I expect > to be the netbios name). > >> so since the DNS is byte oriented, I would have thought >> that the Unicode "DNS name" result would always have a bytes >> equivalent that the DNS resolver code would use - perhaps its >> UTF-8 encoding? > > No no no. When Microsoft calls it the DNS name, they don't actually > mean that it has to do anything with DNS. In particular, it's not > byte-oriented.
Just to clarify: I was proposing to use the GetComputerNameExW() win32 API with ComputerNamePhysicalDnsHostname, which returns Unicode without needing any roundtrip via bytes and the issues associated with this. I don't understand why Martin insists that the MS "DNS name" doesn't have anything to with DNS... the fully qualified DNS name of a machine is determined as hostname.domainname, just like you would expect in DNS. http://msdn.microsoft.com/en-us/library/ms724301(v=VS.85).aspx http://msdn.microsoft.com/en-us/library/ms724224(v=VS.85).aspx As I said earlier: NetBIOS is being phased out in favor of DNS. MS is using a convention which mandates that NetBIOS names match DNS names. The only difference between the two is that NetBIOS names have a length limitation: http://msdn.microsoft.com/en-us/library/ms724931(v=VS.85).aspx Perhaps Martin could clarify why he insists on using the ANSI WinSock interface gethostname instead. PS: WinSock provides many other Unicode APIs for socket module interfaces as well, so at least for that platform, we could use those to resolve uncertainties about the encoding used in name resolution. On other platforms, I guess we'll just have to do some trial and error to see what works and what not. E.g. on Linux it is possible to set the hostname to a non-ASCII value, but then the resolver returns an error, so it's not very practical: # hostname l\303\266wis # hostname löwis # hostname -f hostname: Resolver Error 0 (no error) Using the IDNA version doesn't help either: # hostname xn--lwis-5qa # hostname xn--lwis-5qa # hostname -f hostname: Resolver Error 0 (no error) Python2 happily returns the host name, but fails to return a fully qualified domain name: 'l\xc3\xb6wis' >>> socket.getfqdn() 'l\xc3\xb6wis' and 'xn--lwis-5qa' >>> socket.getfqdn() 'xn--lwis-5qa' Just for comparison: # hostname newton # hostname newton # hostname -f newton.egenix.internal and 'newton' >>> socket.getfqdn() 'newton.egenix.internal' So at least on Linux, using non-ASCII hostnames doesn't really appear to be an option at this time. ---------- _______________________________________ 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
