commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rory Winston (JIRA)" <j...@apache.org>
Subject [jira] Commented: (NET-148) Relaxed condition in __getReply causes other failures.
Date Wed, 20 Feb 2008 14:47:43 GMT

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

Rory Winston commented on NET-148:
----------------------------------

Ok, I think the best way to do this may be to revert to the previous (more strict) behaviour
for default operation, but add a parameter (settable on the FTPClient) which allows the user
to enable strict or lenient multiline parsing.

> Relaxed condition in __getReply causes other failures.
> ------------------------------------------------------
>
>                 Key: NET-148
>                 URL: https://issues.apache.org/jira/browse/NET-148
>             Project: Commons Net
>          Issue Type: Bug
>    Affects Versions: 1.4, Nightly Builds
>            Reporter: Matthew Simoneau
>            Assignee: Rory Winston
>             Fix For: 2.0
>
>
> In FTP.java's __getReply() method, this do/while loop reads multi-line responses from
the server:
>             do
>             {
>                 line = _controlInput.readLine();
> ...
>             }
>             while (!(line.length() >= 4 && line.charAt(3) != '-' &&
>                      Character.isDigit(line.charAt(0))));
>             // This is too strong a condition because of non-conforming ftp
>             // servers like ftp.funet.fi which sent 226 as the last line of a
>             // 426 multi-line reply in response to ls /.  We relax the condition to
>             // test that the line starts with a digit rather than starting with
>             // the code.
>             // line.startsWith(code)));
>         }
> Note the comment and the commented-out termination condition.  I think the relevant spec
is http://www.ietf.org/rfc/rfc0959.txt  and the section is "4.2.  FTP REPLIES".  This is causing
problems with the return from the STAT command from Geocities' FTP servers.  Here is an example
reply.
> 211- ftp.us.geocities.com FTP server status: 
>      Version wu-2.6.0(48) Tue Jan 2 16:30:15 PST 2007 
>  Connected to 144.212.217.85 
>  Logged in anonymously 
>  TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: Stream 
>  No data connection 
>  0 data bytes received in 0 files 
>  0 data bytes transmitted in 0 files 
> 0 data bytes total in 0 files 
> 57 traffic bytes received in 0 transfers 
> 733 traffic bytes transmitted in 0 transfers 
> 834 traffic bytes total in 0 transfers 
> 211  End of status
> Note that the line "0 data bytes total in 0 files" starts with a digit, but it isn't
a reply code.  This prematurely halts reading of lines from the server, and the remaining
lines will look like a reply from the next command.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message