Martin v. Löwis <mar...@v.loewis.de> added the comment: >> Is this patch in response to an actual problem, or a theoretical problem? >> If "actual problem": what was the specific application, and what was the >> specific host name? > > It's about environments, not applications
Still, my question remains. Is it a theoretical problem (i.e. one of your imagination), or a real one (i.e. one you observed in real life, without explicitly triggering it)? If real: what was the specific environment, and what was the specific host name? > There are two points here. One is that the decoding can fail; I > do think that programmers will find this surprising, and the fact > that Python refuses to return what was actually received is a > regression compared to 2.x. True. However, I think this is an acceptable regression, assuming the problem is merely theoretical. It is ok if an operation fails that you will never run into in real life. > That means that when a decoded hostname contains a non-ASCII > character which is not prohibited by IDNA/Nameprep, that string > will, when used in a subsequent call, not refer to the hostname > that was actually received, because it will be re-encoded using a > different codec. Again, I fail to see the problem in this. It won't happen in real life. However, if you worried that this could be abused, I think it should decode host names as ASCII, not as UTF-8. Then it will be symmetric again (IIUC). ---------- 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
