Sebb resolved NET-620.
    Resolution: Unresolved

> 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.3, 3.4, 3.5, 3.6
>         Environment: Java RHEL Linux
>            Reporter: Chris Collins
>            Priority: Major
> 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

Reply via email to