[
https://issues.apache.org/jira/browse/NET-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410592#comment-13410592
]
Gary D. Gregory commented on NET-474:
-------------------------------------
Is it worth discussing adding a lenient vs. strict setting to the FTP class to
allow for such misbehaved servers? The strict mode is as it is now. Lenient
would trim to reply line before attempting to parse it.
If not, what about changing __getReply to protected to allow for overriding?
> Problem, in __getReply method, parsing reply code with leading space
> --------------------------------------------------------------------
>
> Key: NET-474
> URL: https://issues.apache.org/jira/browse/NET-474
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 3.1
> Environment: UNIX
> Reporter: Ahmad AMIN
> Fix For: 3.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> FTPClient.getStatus() function call failed complaining about malformed
> response code.
> After tracing the code, I found the problem at following class and line:
> *org.apache.commons.net.ftp.FTP.__getReply(FTP.java:333)*
> The issue is that this method always expects reply code at position 0 of the
> returned reply string. If the reply string has some leading spaces, it fails
> to parse the reply code and returns malformed reply string.
> Example of such a reply string:
> {noformat}
> 211-nhpssltest Ipswitch FTP Server
> Version 5.0.2
> Connected to 184.70.132.130
> Logged in as massba
> TYPE: ASCII, FORM: Nonprint; STRUcture: File; transfer MODE: STREAM
> No data connection
> 211 End of status
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
