Re: [SQU] Squid is NOT a FTP proxy .. now what ?

Sorry to speak up here..

On Mon, 5 Mar 2001, Adam Lang wrote:

> Ok, I think I get it.
>
> As long as you connect to an ftp server via http:// you are fine.
>
> As soon as you try via ftp:// you are out of luck?
>
> So, if I click on a link to download a file from an ftp server as
> http://ftp.mydomain.com/donloadthis.exe Squid will work.
>
> If I click on a link that does ftp://ftp.mydomain.com/downloadthis.exe Squid
> will not work.

Nope. If you use an http browser which is configured to use a proxy and
then use a link 'ftp://ftp.mydomain.com/downloadthis.exe' the browser
will remember it should use a proxy and ask the proxy (using http
protocol) to retrieve 'ftp://ftp.mydomain.com/downloadthis.exe'.

The proxy will then either use ftp protocol to retrieve the page directly
or use http protocol to ask an 'upstream' cache for it.

In that context, your browser does not act as an ftp client. Basically the
ftp protocol cannot be proxied (maybe gui ftp client could just use an
http proxy and pretend it was a ftp proxy).

A *real* ftp client retrieving ftp://ftp.mydomain.com/downloadthis.exe
will always connect to 'ftp.mydomain.com' (no chance to go to a proxy
instead) login as a user there (although it might often be anonymous)
and then retrieve the file. There is no way it would contact a proxy
instead.

There ARE sort of ftp proxies (suse's so called upcoming firewall toolkit
contains one) which is a local ftp server where you connect to 'some local
proxy machine' login with user name 'remote_user@remote_machine' and the
proxy redirects this to the real ftp client. You typically can not use
these 'ftp proxies' from browsers btw because they misinterprete the '@'
*IN* the username.

In theory a transparent ftp proxy could be written which snoops on the
outgoing ftp traffic and redirects it to a local proxy like the one above
instead. Since ftp is much more complicated when it comes to the lowlevel
network connection than http, this is some non trivial coding to be done.
And it is by no means related to any network aspect of squid. Maybe this
tool could be written to perform the actual downloads by http
requests. Then they could use squid and its cache.

Noone did it *AND* noone wants to do it, since: Just use a http client
(browser or commandline tool under unix) for the ftp url and use a http
client.

Using their browser and squid (or some other http proxy) your users can
get ftp pages.. so, why write yet another, more complex program for it?

I fail to see any real reasons for an ftp proxy. If you need some specific
enhancements and site commands of the ftp protocol this is beyond a cache
anyway. Just allow this ftp traffic through your firewall. Maybe restrict
yourself to passive mode ftp for the sake of security. Anyway, such
proxies using name@machine as user exist. Caching makes not too much sense
here, so I don't see squid here.

If you *just* want to download a file.. do it through a http proxy anyway.
Probably your problem is that you have some broken applications that
insist on using the ftp protocol and you can't change it. Well ftp per se
cannot be proxied. Fix the application or reconfigure your firewall.

I think there is some confusion here comparing an ftp or http download
lowlevel on tcp connection level and the request (performed using http
protocol) to a http proxy to retrieve an ftp:<...> URL.

You might also be confused by MS Proxy which has a mode to proxy ANY
tcp connection (including ftp). This is not related to caching at all
so not the job of squid. You can achieve the same with masquerading and
proper routing (probably a private class A net) with no special client
at all. But this is not related to squid.

Michael.

--
Michael Weller: eowmob@exp-math.uni-essen.de, eowmob@ms.exp-math.uni-essen.de,
or even mat42b@spi.power.uni-essen.de. If you encounter an eowmob account on
any machine in the net, it's very likely it's me.
--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html