commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Collins (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (NET-620) Strict CRLF handling in Commons-NET FTP breaks compatibility with some FTP servers
Date Fri, 03 Mar 2017 00:44:45 GMT

    [ https://issues.apache.org/jira/browse/NET-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15893417#comment-15893417
] 

Chris Collins edited comment on NET-620 at 3/3/17 12:44 AM:
------------------------------------------------------------

So rather than bothering with an extra class in my code I'm just going to handle it like this:

{noformat}
public class FTPClient extends org.apache.commons.net.ftp.FTPClient
{
    /**
     * Overridden version of org.apache.commons.net.ftp.FTPClient to convert all
     * line termination to CRLF regardless of source for compatibility with non-conforming
     * FTP servers.
    */
    @Override
    protected void _connectAction_() throws IOException
    {
    	ToNetASCIIInputStream toNetAsciiIs = new ToNetASCIIInputStream(_input_);
    	InputStreamReader isr = new InputStreamReader(toNetAsciiIs, getControlEncoding());
    	_connectAction_(isr);
    }	
}

{noformat}

This should handle it in-line, I'll give this a go later and see how I make out.


was (Author: unsta):
So rather than bothering with an extra class in my code I'm just going to handle it like this:

{noformat}
public class FTPClient extends org.apache.commons.net.ftp.FTPClient
{
    /**
    * Overridden version of org.apache.commons.net.ftp.FTPClient to convert all
    * line termination to CRLF regardless of source for compatibility with non-conforming
    * FTP servers.
    */
    @Override
    protected void _connectAction_() throws IOException
    {
    	ToNetASCIIInputStream toNetAsciiIs = new ToNetASCIIInputStream(_input_);
    	InputStreamReader isr = new InputStreamReader(toNetAsciiIs, getControlEncoding());
    	_connectAction_(isr);
    }	
}

{noformat}

This should handle it in-line, I'll give this a go later and see how I make out.

> 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)

Mime
View raw message