Chris Collins created NET-620:
---------------------------------
Summary: Strict CRLF handling in Commons-NET FTP breaks
compatibility with some FTP servers
Key: NET-620
URL: https://issues.apache.org/jira/browse/NET-620
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.6, 3.5, 3.4, 3.3
Environment: Java RHEL Linux
Reporter: Chris Collins
The fix for FTP.java in NET-401 to switch from using BufferedReader to
CRLFLineReader breaks the ability to connect to servers that have varying LF
and CRLF line termination in the banner.
I've run into 2 different cases with slightly different banner configs, one
where you end up hung indefinitely by not reading far enough (this is the
sigquit from when it is hung):
1. Thread=FTP Provider Protocol Provider Thread: class com.xxxx.xxxxx.xxx
(00007F35A1AF4A00) Status=Running
at
java/net/SocketInputStream.socketRead0(Ljava/io/FileDescriptor;[BIII)I (Native
Method)
at java/net/SocketInputStream.read([BIII)I (SocketInputStream.java:164)
(Compiled Code)
at java/net/SocketInputStream.read([BII)I (SocketInputStream.java:134)
(Compiled Code)
at sun/nio/cs/StreamDecoder.readBytes()I (StreamDecoder.java:323)
(Compiled Code)
at sun/nio/cs/StreamDecoder.implRead([CII)I (StreamDecoder.java:365)
(Compiled Code)
at sun/nio/cs/StreamDecoder.read([CII)I (StreamDecoder.java:211)
(Compiled Code)
at java/io/InputStreamReader.read([CII)I (InputStreamReader.java:206)
(Compiled Code)
at java/io/BufferedReader.fill()V (BufferedReader.java:166) (Compiled
Code)
at java/io/BufferedReader.read()I (BufferedReader.java:187) (Compiled
Code)
at org/apache/commons/net/io/CRLFLineReader.readLine()Ljava/lang/String;
(CRLFLineReader.java:58)
at org/apache/commons/net/ftp/FTP.__getReply(Z)V (FTP.java:357)
at org/apache/commons/net/ftp/FTP.__getReply()V (FTP.java:300)
at org/apache/commons/net/ftp/FTP._connectAction_(Ljava/io/Reader;)V
(FTP.java:438)
at
org/apache/commons/net/ftp/FTPClient._connectAction_(Ljava/io/Reader;)V
(FTPClient.java:962)
at org/apache/commons/net/ftp/FTPClient._connectAction_()V
(FTPClient.java:950)
at
org/apache/commons/net/SocketClient._connect(Ljava/net/InetAddress;ILjava/net/InetAddress;I)V
(SocketClient.java:244)
at org/apache/commons/net/SocketClient.connect(Ljava/net/InetAddress;I)V
(SocketClient.java:181)
2. And one where you error out by reading too far and getting a null back:
Caused by:
org.apache.commons.net.ftp.FTPConnectionClosedException: Connection closed
without indication.
at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:317)
at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:294)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:483)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:608)
at org.apache.commons.net.ftp.FTP.user(FTP.java:753)
at org.apache.commons.net.ftp.FTPClient.login(FTPClient.java:1034)
I do have hex data available to show the source data, but the end result is
there's a mix of 0d0a (CRLF) and 0a (LF) termination in the FTP banner (220-)
I can modify the library to undo the NET-401 change, but ideally it'd be nice
to have a strictNewline type of setting you could set on the FTPClient object
to decide if you want to be ultra-strict, or ultra compatible. I will be filing
a defect with Cisco about this as well, but it would be great if the FTPClient
had the option to handle it instead of forced compatibility with no options to
relax it.
This is kind of hinted at in one of the comments on NET-402 by Bogdan
Drozdowski on 12/Apr/11
"So, on one hand, we stop supporting non-conforming servers (which could mean
that we're supporting less servers now), but on the other hand we're fixing a
bug that someone has found in a real-life system."
Giving users the option to relax the conformity requirements (but strict by
default) would allow the end user to choose the option.
Any thoughts on this?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
