Author giampaolo.rodola
Recipients SebastianGPedersen, benjamin.peterson, corona10, eric.smith, ezio.melotti, giampaolo.rodola, inada.naoki, lemburg
Date 2020-01-25.16:38:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1579970308.91.0.678130421508.issue39380@roundup.psfhosted.org>
In-reply-to
Content
It's been a long time since I implemented UTF-8 support in pyftpdlib, but long story short is that:
- most recent servers are supposed to use UTF-8 by default
- such servers must include "UTF-8" in the FEAT command response
- some servers may enable UTF-8 only if client explicitly sends "OPTS UTF-8 ON" first, but that is based on an draft RFC. Server implementors usually treat this command as a no-op and simply assume UTF-8 as the default.

With that said, I am -1 about implementing logic based on FEAT/OPTS: that should be done before login, and at that point some servers may erroneously reject any command other than USER, PASS and ACCT. 

Personally I think it makes more sense to just use UTF-8 without going through a deprecation period, document *encoding* attribute and mention that in order to deal with servers not supporting UTF8 you can pre-emptively check FEAT response and set ASCII encoding. But I am not a unicode expert, so I would like to hear some other opinion re. the implications of going from latin-1 to utf8 in terms of potential code breakage.
History
Date User Action Args
2020-01-25 16:38:28giampaolo.rodolasetrecipients: + giampaolo.rodola, lemburg, eric.smith, benjamin.peterson, ezio.melotti, inada.naoki, corona10, SebastianGPedersen
2020-01-25 16:38:28giampaolo.rodolasetmessageid: <1579970308.91.0.678130421508.issue39380@roundup.psfhosted.org>
2020-01-25 16:38:28giampaolo.rodolalinkissue39380 messages
2020-01-25 16:38:28giampaolo.rodolacreate