You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Matthew Simoneau (JIRA)" <ji...@apache.org> on 2007/01/05 00:32:27 UTC
[jira] Created: (NET-148) Relaxed condition in __getReply causes
other failures.
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 Final
Reporter: Matthew Simoneau
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.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Reopened: (NET-148) Relaxed condition in __getReply causes
other failures.
Posted by "Matthew Simoneau (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthew Simoneau reopened NET-148:
----------------------------------
This is still broken in the nightly build. Here is a simple Java program that will reproduce this.
import org.apache.commons.net.ftp.FTPClient;
public class FTPTest {
public static void main(String[] args) throws Exception {
FTPClient ftpClient = new FTPClient();
ftpClient.connect("ftp.us.geocities.com",21);
ftpClient.login("anonymous","anonymous@example.com");
ftpClient.getStatus();
System.out.println(ftpClient.listFiles());
ftpClient.disconnect();
}
}
getStatus() stops reading lines prematurely, which sets up listFiles() to fail.
> 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
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Updated: (NET-148) Relaxed condition in __getReply causes
other failures.
Posted by "Rory Winston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rory Winston updated NET-148:
-----------------------------
Fix Version/s: 2.0
> 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
> Assigned To: 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Commented: (NET-148) Relaxed condition in __getReply causes
other failures.
Posted by "Rory Winston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498429 ]
Rory Winston commented on NET-148:
----------------------------------
Thanks Matthew , that is very helpful. I can reproduce the issue now. I think we may need to modify that condition to fix this.
> 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
> Assigned To: Rory Winston
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Resolved: (NET-148) Relaxed condition in __getReply causes
other failures.
Posted by "Rory Winston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rory Winston resolved NET-148.
------------------------------
Resolution: Cannot Reproduce
I have tried this with Geocities servers, but I cant reproduce the issue with 2.0 RC? Can you provide some more info?
> 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
> Reporter: Matthew Simoneau
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Updated: (NET-148) Relaxed condition in __getReply causes
other failures.
Posted by "Matthew Simoneau (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthew Simoneau updated NET-148:
---------------------------------
Affects Version/s: Nightly Builds
> 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
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org