Return-Path: Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org Received: (qmail 94717 invoked from network); 8 Feb 2007 18:06:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 Feb 2007 18:06:29 -0000 Received: (qmail 61159 invoked by uid 500); 8 Feb 2007 18:06:33 -0000 Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org Received: (qmail 60318 invoked by uid 500); 8 Feb 2007 18:06:31 -0000 Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Users List" Reply-To: "Jakarta Commons Users List" Delivered-To: mailing list commons-user@jakarta.apache.org Received: (qmail 60307 invoked by uid 99); 8 Feb 2007 18:06:31 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Feb 2007 10:06:31 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [38.100.86.39] (HELO jamm6.JAMMConsulting.com) (38.100.86.39) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Feb 2007 10:06:21 -0800 Received: from neilhp (jamm6.JAMMConsulting.com [127.0.0.1]) (authenticated bits=0) by jamm6.JAMMConsulting.com (8.13.5/8.13.5) with ESMTP id l18I5wlU025403 for ; Thu, 8 Feb 2007 12:06:00 -0600 From: "Neil Aggarwal" To: "'Jakarta Commons Users List'" Subject: RE: [net-ftp] FTPS timeout when trying to upload a file Date: Thu, 8 Feb 2007 12:05:55 -0600 Organization: JAMM Consulting, Inc. Message-ID: <000a01c74bab$c7da45d0$6501a8c0@neilhp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <007201c74ba4$cc9e88d0$0b4613ac@shs1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdLMay1pElm+B0bSt6lk35vaBHZUAABkD1wAAj4aAAADYN9IAAAwUkgAAPJAKAAAcYN4A== X-Virus-Scanned: ClamAV 0.88.4/2534/Wed Feb 7 21:28:17 2007 on jamm6.JAMMConsulting.com X-Virus-Status: Clean X-Virus-Checked: Checked by ClamAV on apache.org Steffen: 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. Thanks, Neil -- Neil Aggarwal, (214)986-3533, www.JAMMConsulting.com FREE! Eliminate junk email and reclaim your inbox. Visit http://www.spammilter.com for details. -----Original Message----- From: Steffen Heil [mailto:lists@steffen-heil.de] 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 Hi > 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 involved.) 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. Regards, Steffen --------------------------------------------------------------------- To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-user-help@jakarta.apache.org