On 14 Apr 2003 at 10:48, Roth, Kevin P. wrote:

> I'd envision the -x/--proxy option being changed to support the
> standard FTP proxy methods, in addition to the HTTP options they now
> support. These almost always involve FTP'ing to a proxy (or more
> typically a firewall) server, and then using some wacky combination of
> proxy (firewall) ID's combined with the real FTP server's username. In
> many cases, the firewall/proxy doesn't require it's own password...
>
> We'd also need to have the -U/--proxy-user option enhanced to work
> with these FTP proxies.

That makes sense.

On the other hand, using new options means that users will be able to
pre-set proxy-user differently for HTTP and FTP in their ~/.curlrc.
(Though I don't know how often they will be different; I imagine that
if a site has an HTTP and an FTP proxy and they both require
authentication, they will accept the same credentials. Requiring them
to be the same, or requiring explicit overriding on the commandline,
may be sufficient.)

On the other hand, -x/--proxy may need to receive a new name... in our
company, both proxies run on a host called "proxy", but I can imagine a
site with an HTTP proxy on wwwproxy:3128 and an FTP proxy on
ftpproxy:21, i.e. two different hostnames. Being able to specify
defaults for *both* of these in the ~/.curlrc would be useful, then.

> Finally, we'd need to introduce some new option (perhaps
> --ftp-proxy-type) that would tell curl what to do with the proxy info
> for an FTP request. The DEFAULT would need to be "HTTP", so that
> today's behavior is unmodified. The default port for FTP-protocol
> proxies should be 21, rather than 1080...

Yes, something like that would be needed, too.

> A tool I often use (FileZilla) shows the following options:
>
> SITE hostname (followed by USER,PASS in the usual fashion)
> USER after logon (not sure how this one actually works)
> Proxy OPEN (presumably USER,PASS to the proxy, then another OPEN command...)
> Transparent (???)
> USER with no logon (???)
> USER FireID_at_Remotehost (PASS FirePass_at_RemotePass)
> USER RemoteID_at_remoteHost FireID (PASS RemotePass FirePass)
> USER RemoteID_at_FireID@RemoteHost (PASS RemotePass_at_FirePass, this is Firewall-1's approach)

That's similar to what's in my ~/.ncftp/firewall file:

# Types of firewalls:
# ------------------
#
# type 1: Connect to firewall host, but send "USER
user_at_real.host.name"
#
# type 2: Connect to firewall, login with "USER fwuser" and
# "PASS fwpassword", and then "USER user_at_real.host.name"
#
# type 3: Connect to and login to firewall, and then use
# "SITE real.host.name", followed by the regular USER and
PASS.
#
# type 4: Connect to and login to firewall, and then use
# "OPEN real.host.name", followed by the regular USER and
PASS.
#
# type 5: Connect to firewall host, but send
# "USER user_at_fwuser@real.host.name" and
# "PASS pass_at_fwpass" to login.
#
# type 6: Connect to firewall host, but send
# "USER fwuser_at_real.host.name" and
# "PASS fwpass" followed by a regular
# "USER user" and
# "PASS pass" to complete the login.
#
# type 7: Connect to firewall host, but send
# "USER user_at_real.host.name fwuser" and
# "PASS pass" followed by
# "ACCT fwpass" to complete the login.
#
# type 0: Do NOT use a firewall (most users will choose this).

> FileZilla source code is available (SourceForge), so someone with
> enough time to implement this should be able to look up and see how
> these are used behind the scenes.

That's interesting.

Cheers,
Philip

-- 
Philip Newton <pnewton_at_gmx.de>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf