commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neil Aggarwal" <>
Subject RE: [net-ftp] FTPS timeout when trying to upload a file
Date Thu, 08 Feb 2007 18:05:55 GMT

If the server is running on a private IP, how can you 
expect it to know anything except the private IP?
A NAT route is upstream of the server.

As I said, I do not control the server.  The company
that hired me will not accept me telling them the
server from their vendor is broken and
that my code will not work.

Given the discussion below, we need a solution that allows 
the user to force an override for the IP address used for 
passive connections.


Neil Aggarwal, (214)986-3533,
FREE! Eliminate junk email and reclaim your inbox.
Visit for details.

-----Original Message-----
From: Steffen Heil [] 
Sent: Thursday, February 08, 2007 11:16 AM
To: 'Jakarta Commons Users List'
Subject: RE: [net-ftp] FTPS timeout when trying to upload a file


> I could be on a private subnet which is the same private 
> subnet as the server.  But, we could be in different locations.
> In that case, the solution below won't work.
> How about we do this:
> If (The IP given by the server is a private address)
>   Always use the IP given by the call to
>   the connect command.
> else
>   Use the IP given by the server.
> That should fix this problem.

I wouldn't do so.

That SERVER is broken and needs to be fixed.
There is nothing a client can do.

Please DO NOT try to handle that on the client. You cannot.

First, there are cases where servers actually USE different IPs for control
and data connections, which is absolutely legal. (It is even essential if
you use FXP capabilities, which is basically pure FTP with 2 servers

Second, there ARE cases where servers with public OR private ips are NATed
to private IPs. [And maybe even from one private ip to another private ip.]
If you even happen to be on the same subnet as such a server, you still want
to be able to connect.

Again, the server is broken. Get it fixed. Or reject to use it.
DON'T CHANGE THE CLIENT. Especially don't give it any strange semantic
rules, that make understanding problems impossible, if there is ever a
situation that you didn't expect. If at all, give the use a change to
optionally overwrite used IPs.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message