[
https://issues.apache.org/jira/browse/NET-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15893679#comment-15893679
]
Chris Collins commented on NET-620:
-----------------------------------
Well it definitely used it upon connection, but gets an NPE on the reader.
{noformat}
java.lang.NullPointerException
at
org.apache.commons.net.io.ToNetASCIIInputStream.available(ToNetASCIIInputStream.java:177)
at
org.apache.commons.net.io.ToNetASCIIInputStream.read(ToNetASCIIInputStream.java:139)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:323)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:365)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:211)
at java.io.InputStreamReader.read(InputStreamReader.java:206)
at java.io.BufferedReader.fill(BufferedReader.java:166)
at java.io.BufferedReader.read(BufferedReader.java:187)
at org.apache.commons.net.io.CRLFLineReader.readLine(CRLFLineReader.java:58)
at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:321)
at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:300)
at org.apache.commons.net.ftp.FTP._connectAction_(FTP.java:438)
at org.apache.commons.net.ftp.FTPClient._connectAction_(FTPClient.java:962)
at
com.q1labs.semsources.sources.remote.transferprotocol.ftp.FTPClient._connectAction_(FTPClient.java:28)
at org.apache.commons.net.SocketClient._connect(SocketClient.java:244)
at org.apache.commons.net.SocketClient.connect(SocketClient.java:181)
{noformat}
ToNetASCIIInputStream.java:177 is
{noformat}
result = in.available();
{noformat}
Having a look through though _input_ is initialized in SocketClient
_connectAction which is called by FTP.java _connectAction_ which is called by
FTPClient.java _connectAction_ so it presumably should be populated.
So the inputStream must be null at that point, but I'll have to remote debug it
to dig further.
> 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
>
> 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)
