Кстати, автор отозвался, и маленькая часть репорта (багфикс) уже в CVS. Также я думаю попытаться включить в baseline фикс для русской "я" в CP1251.
Чтобы понять суть проблемы я полез для начала в код proftpd и патч для исправления этой проблемы. Оказалось, что дело в том, что "я", имеет код 0xFF, который в свою очередь используется в протоколе TELNET (RFC854) как символ IAC
All TELNET commands consist of at least a two byte sequence: the
"Interpret as Command" (IAC) escape character followed by the code
for the command. The commands dealing with option negotiation are
three byte sequences, the third byte being the code for the option
referenced. This format was chosen so that as more comprehensive use
of the "data space" is made -- by negotiations from the basic NVT, of
course -- collisions of data bytes with reserved command values will
be minimized, all such collisions requiring the inconvenience, and
inefficiency, of "escaping" the data bytes into the stream. With the
current set-up, only the IAC need be doubled to be sent as data, and
the other 255 codes may be passed transparently.
При чём тут телнет, если мы говорим о FTP, спросите вы? А очень просто. RFC959 (FTP) чётко говорит о том, что
The File Transfer Protocol follows the specifications of the Telnet
protocol for all communications over the control connection. Since
the language used for Telnet communication may be a negotiated
option, all references in the next two sections will be to the
"Telnet language" and the corresponding "Telnet end-of-line code".
Currently, one may take these to mean NVT-ASCII and <CRLF>. No other
specifications of the Telnet protocol will be cited.
и там же
The Relationship between FTP and Telnet:
The FTP uses the Telnet protocol on the control connection.
This can be achieved in two ways: first, the user-PI or the
server-PI may implement the rules of the Telnet Protocol
directly in their own procedures; or, second, the user-PI or
the server-PI may make use of the existing Telnet module in the
system.
Ease of implementaion, sharing code, and modular programming
argue for the second approach. Efficiency and independence
argue for the first approach. In practice, FTP relies on very
little of the Telnet Protocol, so the first approach does not
necessarily involve a large amount of code.
Теперь, зачем же proftpd потребовался код IAC? Он его использует очень забавно - для того, чтобы сообщить что его имплементация телнета - ничего не умеет и ничего делать не будет, т.е. максимально тупой терминал. А именно - на все запросы типа WILL/WONT отвечает DONT и на DO/DONT - WONT. Ни 1 из известных мне ftp клиентов не пытается делать escape для 0xff и таким образом мы имеем то, что следующий за "я" символ воспринимается как как команда и благополучно глотается. Думаю, что этот кусок кода с WILL/WONT был сделан для каких-то очень старых и глючных терминалов или ftp клиентов. По крайне мере я таких не видел. Полагаю, что будет вполне уместно сделать setting вроде TelnetEmuDisable или как-то так, который позволит вырубать кусок кода связанного с IAC.
Впрочем, есть мнение, что отключение обработки IAC приведит к нарушению RFC:
4.1.2.12 Connections: RFC-959 Section 5.2
The words "and the port used" in the second paragraph of
this section of RFC-959 are erroneous (historical), and they
should be ignored.
On a multihomed server host, the default data transfer port
(L-1) MUST be associated with the same local IP address as
the corresponding control connection to port L.
A user-FTP MUST NOT send any Telnet controls other than
SYNCH and IP on an FTP control connection. In particular, it
MUST NOT attempt to negotiate Telnet options on the control
connection. However, a server-FTP MUST be capable of
accepting and refusing Telnet negotiations (i.e., sending
DONT/WONT).
DISCUSSION:
Although the RFC says: "Server- and User- processes
should follow the conventions for the Telnet
protocol...[on the control connection]", it is not the
intent that Telnet option negotiation is to be
employed.
Теперь перейдём от теории к практике. Я испытал 2 клиента для того на предмет обработки злосчастного символа 0xFF. Первым был FileZilla. Есть мнение, что всем известным ftp клиентам вообще наплевать на обработку IAC. По крайне мере ни FileZilla ни mc не посылают 0xFF два раза вместо одного. Более того, получая 1 0xFF они честно отрисовывают его как "я", а вовсе не переходят в режим control, как того требует telnet rfc. Причём в профтпд без cyrfix патча обработка символа 0xff соотв. RFC, т.е. два символа воспринимаются как 1. Хотя в отдаваемой им информации он тоже не ескейпит этот символ, таким образом также нарушая станарт.
Резюме: если сделать минификс к proftpd, заменяющий в control output 0xff на 0xff 0xff - не изменится ровным счётом ничего, так как клиенты всё равно эту часть стандарта не реализовали. А патч, отключающий процессинг IAC приведёт к нарушению сервером RFC. Наглядный пример к чему приводит игнорирование стандартов, а также добавление в RFC нафиг там ненужных вещей, вроде IAC процессинга.
.
