Message114756
| 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). |
|