This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients baikie, ezio.melotti, lemburg, loewis, vstinner
Date 2010-08-23.23:07:04
SpamBayes Score 1.5922727e-06
Marked as misclassified No
Message-id <4C72FF16.6040800@v.loewis.de>
In-reply-to <20100823224813.GB5500@dbwatson.ukfsn.org>
Content
>> 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).
History
Date User Action Args
2010-08-23 23:07:06loewissetrecipients: + loewis, lemburg, vstinner, baikie, ezio.melotti
2010-08-23 23:07:05loewislinkissue9377 messages
2010-08-23 23:07:04loewiscreate