commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [NET] Errorhandling of "bad" FTP Servers
Date Mon, 23 Jan 2017 16:33:16 GMT
On 23 January 2017 at 07:31, Oliver Zemann <> wrote:
>>> 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.
>> setAutodetectUTF8 only sets a flag which is consulted during connect;
>> it does not send anything to the server.
> When autodetectUTF8() is set to true, after the connect, apache commons net
> sends a FEAT to check if the server supports UTF8. This is what FileZilla
> does not. Therefore, with FileZilla its working.
> When i remove autodetectUTF8(true) in my code, it works. But thats no
> solution to me because i would like to have UTF8 support.
>>> 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()
>> That is perfectly reasonable behaviour for FileZilla and for Commons NET.
> commons net sends the FEAT _before_ the USER command is send. Thats a big
> difference in FileZilla and commons net.

But it does so only if setAutodetectUTF8 is true.

So another workround is not to set that.

But in any case, the server would still send the MODE Z incorrectly,
as proven by the FileZilla session log.

>> No, there is no such method.
>> You could try calling getReply() and catching IO errors.
>> However if there is no data to read that will likely hang.
>> It so, try setting a timeout.
>> You could also try subclassing FTPClient and then you can access the
>> _controlInput_ field.
>> This is where the replies are read from.
>> However reading from the control channel may cause NET to break in subtle
>> ways.
> Thanks, guess i will try it that way.
>> AFAIK this is the first time this problem has been reported.
>> Which seems odd if there really are thousands of servers with this
>> behaviour.
> I did not mean "thousands of servers with this behaviour" i meant: there are
> thousands of servers i access, i can contact them and tell them they have
> broken ftp server software, but they probably simply don't care.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message