I understand your motivation to limit support of specialized situations,
and wholeheartedly agree. My inclination is that this situation would exist
any time that an "older" FTP/SSL host is dropped behind a NAT firewall, and
is therefore not that specialized.
I am certain that in most situations involving the Sterling server, the
client side simply buys the Sterling client. In my situation, however, I am
running a highly automated file distribution system, with very few
resources. The Sterling client is beyond my (nearly nonexistent) budget,
and does not integrate nicely with my now rather large Perl script.

However, I will certainly defer to your judgement.
I suppose can maintain the needed patch on my own.

Thanks Daniel and all!

Ed Hingsbergen

|---------+--------------------------------->
| | Daniel Stenberg |
| | <daniel-curl_at_haxx.se> |
| | Sent by: |
| | curl-library-bounces_at_c|
| | ool.haxx.se |
| | |
| | |
| | 10/05/2004 09:27 AM |
| | Please respond to |
| | libcurl development |
| | |
|---------+--------------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
  | |
  | To: libcurl development <curl-library_at_cool.haxx.se> |
  | cc: |
  | Subject: Re: FTP_IGNORE_PASSIV_IP |
>------------------------------------------------------------------------------------------------------------------------------|

On Tue, 5 Oct 2004 ED_Hingsbergen_at_cisgi.com wrote:

> The servers I've encountered have all been part of the Sterling Commerce
> CONNECT product. Sterling's software is very popular for electronic
> commerce/EDI systems. Such commercial software products often carry a
legacy
> with it, and are not particularly up-to-date. The fact that it has the
227
> PASV/NAT firewall clash is likely viewed by Sterling as an asset, since
they
> sell an FTPS client that handles the problem. By adding
> FTP_IGNORE_PASSIVE_IP, curl can be used instead of having to purchase a
> commercial client that has none of the programmability of curl.

I understand all this.

There's just this very annoying nudging feeling in the back of my head,
that
this option would be used only against these "Sterling" products because
they
are inferior and want their customers to use their own clients.

I don't think it is curl's job to work around artificial limits introduced
by
silly companies.

curl speaks FTP, and by doing what they do, I would argue that they no
longer
adheres to the RFC959 spec and they are therefore no longer speaking FTP by

definition. EPSV is not RFC959 either, but it is present in a public
extension
document followed by a massive amount of clients and servers.

> Saying "Just make sure your server supports EPSV" clearly demonstrates a
> lack of understanding of the situation. IT'S NOT MY SERVER!!!!!

Saying this problem is solved in the rest of the world by the server
responding to EPSV is showing that we understand the technical reason why
you
need to do your hack and what the server could do to fix their problem. We
just aren't accepting the political reasons why this isn't possible in this

case.

What if another company thinks is a good idea to send back a 237 response
instead with the ip address in reversed order? Should we then introduce
another option to work with their ways? Where does it stop?

--
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
       Dedicated custom curl help for hire: http://haxx.se/curl.html