Please prefix the subject line with the Commons Component in future (as above)
Sorry, next time i will do that.
On 22 January 2017 at 09:12, Oliver Zemann <oliver.zem...@gmail.com> wrote:
Hi, i would like to know how to handle FTP Servers that do not behave like
they should (or behave different than most others).
For example, currently i would like to connect to one of those servers which
sends " MODE Z" directly after a login (USER) which is interpreted wrong by
apache commons ftp, as its assumed that there should be \d\d\d \w* like "220
all good my friend"
But its simply: " MODE Z"
Here is a log from filezilla which can handle this behaviour:
09:58:24 Trace: CFtpControlSocket::SendNextCommand()
09:58:24 Befehl: USER someUser
09:58:24 Trace: CFtpControlSocket::OnReceive()
09:58:24 Antwort: 331 [33m ~wait~ user ok, password?
09:58:24 Trace: CFtpControlSocket::SendNextCommand()
09:58:24 Befehl: PASS *******
09:58:25 Trace: CFtpControlSocket::OnReceive()
09:58:25 Antwort: 230 [32m.::WAIT::. welcome!.
The login has completed here
Yes, but apache commons sends first FEAT when i use autodetectUTF8(),
which is imo wrong.
The javadoc states that autodetectUTF8() has to be used before
connect(), but i dont understand why.
FileZilla first connects and does the login() and after that it uses the
FEAT command to check if the server supports UTF8.
The server behaves "bad" of that FEAT command, because it sends 211 END
but then outputs MODE Z (which should before 211 END). And FEAT is
issued because of autodetectUTF8()
Would it be possible to read from _controlInput_ until null is returned?
Seems like someone else encountered something with another server, and
therefore __ lenientCheck() exists?
09:58:25 Befehl: FEAT
09:58:25 Trace: CFtpControlSocket::OnReceive()
09:58:25 Antwort: 211-Extension supported
09:58:25 Antwort: MDTM
09:58:25 Antwort: MDTM
09:58:25 Antwort: MDTM YYYYMMDDHHMMSS[+-TZ];filename
09:58:25 Antwort: SIZE
09:58:25 Antwort: SITE PSWD;EXEC;SET;INDEX;ZONE;CHMOD;MSG
09:58:25 Antwort: XCRC filename;start;end
09:58:25 Antwort: 211 End
09:58:25 Status: Der Server unterstützt keine Nicht-ASCII-Zeichen.
09:58:25 Status: Angemeldet
09:58:25 Antwort: MODE Z
09:58:25 Trace: Unexpected reply, no reply was pending. <----
something like this in apache commons ftp???
Note that FileZilla detects this as an error, so clearly this is not
expected behaviour.
Commons NET only looks for a reply when one is expected, so it cannot
detect this.
AFAICS changing this would require a major rewrite.
Since the server appears to be broken, it's not worth doing this.
That means, if a server answers a request wrong (like on that server
with FEAT, because MODE Z should be before 211 END), all further
communication with apache commons net ftp is impossible to that server
because _controlInput_ is not "cleared"?
Is there some kind of "clearControlInput()" method the user can invoke
to "clear" all (possible) invalid data to make the ftp client more
"stable" when it has to deal with such ftp servers? Because then i could
simply call "clearControlInput()" each time before i send my commands.
Some information: i dont have control over that server. I dont know what
software the server is running.
Try contacting the server maintainers to raise the issue of the
server's bad behaviour
Unfortunately this is one of many thousands of servers, located
somewhere... china, russia, usa etc.
I guess some of those servers are even not maintained anymore. So this
is not a solution. I have to somehow handle those servers :(
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
