[
https://issues.apache.org/jira/browse/NET-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316532#comment-16316532
]
Filipe Bojikian Rissi commented on NET-649:
-------------------------------------------
My code:
{code:java}
private class FTPClientCustom extends FTPClient {
private final Pattern __PARMS_PAT =
Pattern.compile("(\\d{1,3},\\d{1,3},\\d{1,3},\\d{1,3}),(\\d{1,3}),(\\d{1,3})");
@Override
protected void _parsePassiveModeReply(String reply) throws
MalformedServerReplyException {
final Matcher m = __PARMS_PAT.matcher(reply);
if (!m.find()) {
throw new MalformedServerReplyException(
"Could not parse passive host information.\nServer
Reply: " + reply);
}
final String __passiveHost = m.group(1);
if ("0,0,0,0".equals(__passiveHost)) {
reply = reply.replaceFirst("0,0,0,0", server.replace('.', ','));
}
super._parsePassiveModeReply(reply);
}
}
{code}
My Fork:
{code:java}
__passiveHost = "0,0,0,0".equals(m.group(1)) ?
_socket_.getInetAddress().getHostAddress() :
m.group(1).replace(',', '.'); // Fix up to look like IP address
{code}
I found the change interesting, because the exception is not at all clear that
there is a problem with the server, the only reason I know it was, is that I
debugged the Commons-Net and compared what File Zila wrote in the log.
So I did with inheritance in my code and to contribute with possible problems
that others may have I made a formk and requested a Pull Request, I'm not
compiling with the fork.
> 227 Entering Passive Mode
> -------------------------
>
> Key: NET-649
> URL: https://issues.apache.org/jira/browse/NET-649
> Project: Commons Net
> Issue Type: New Feature
> Components: FTP
> Affects Versions: 3.6
> Environment: Fedora, Java 8
> Reporter: Filipe Bojikian Rissi
> Fix For: 3.7
>
>
> In a situation where I passed, the FTP server is restoring 227 Entering
> Passive Mode (0,0,0,0,156,126), so it was obvious to me that the problem is
> on the server side and not on the API, but using the File Zila client and
> analyze the log precebi that the same problem was also happening, so he
> changed the route to use the IP of the server that returned this information
> and thus manages to make the route correctly.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
