[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Patch to add direct FTP proxy support in kio_ftp
From:       Michael Goffioul <goffioul () imec ! be>
Date:       2001-06-28 9:43:38
[Download RAW message or body]

> Hi Michael,
> 
> Personally I see few problems with this patch:

I never said it was THE patch. I posted to points the needed changes to
support a real FTP proxy server (DeLeGate). It was hard to dig into kio/ftp
code and I'm pretty sure I didn't get everything, so I choose the easiest
solutions. Someone involved in kio development would probably find more
elegant solutions that does the same.

> The first one of my concerns/problems is with the '@' workaround.  IMHO noone
> should circumvent a standard and send un-encoded '@' when the specification
> explicitly states otherwise.  See RFC 2396 section 3.2.  Though this might have
> worked for you in this particular scenario for now, there is no guarantee this will
> work on for everyone or even for you down the road because the remote machine(s)
> at some point and time might not accept the un-encoded '@' in the username.  You
> have to be careful with such hacks since it possibly involves machines beyond your
> control.  My only advice here is you change the username if possible.

I didn't get your point here. The patch I posted avoid having username in the URL
in the form of login@host:port, so you don't have garbage '@' anymore. On the other
hand the patch simply change how the ftp ioslave issues a "USER" command: instead
of the form "USER login", it issues "USER login@remote:host". But this command
is issued to the FTP proxy server (not the target remote FTP server) and this
proxy server SHOULD understand it, as it is how it works. The FTP proxy server
does NOT ask for "USER login%40host:port" with the '@' encoded, it simply won't
work. So I don't see the point here with the encoded '@'.

> The other problem is that the KProtocolManager patch is well wrong for luck of better
> words.  We currently do not allow per-host proxy settings.  The proxy settings are
> global and the actual method you want to change is KProtocolManager::slaveProtocol().
> In there we simply assume that everything that uses proxy uses an http proxy.  We
> should instead obtain the protocol from the set proxy address to allow for this type
> of proxying.  Then all you have to do is to simply enter the correct proxy address at
> the config dialog.  Fixed.

I see 2 problems to this way:
- the protocol used for FTP proxy is http, you don't have any control on this in the
  config dialog
- this won't work with auto-proxy configuration, which is my case, because what you
  propose implies to use manual proxy configuration, an auto-proxy will override
  everything, and the auto-proxy will of course redirect you to the classical HTTP 
  proxy

Here, we have a auto-proxy configuration (for HTTP and FTP) and a real FTP proxy server.
The patch I proposed allows you to use the HTTP auto-proxy for http request AND the
real FTP proxy for ftp request. By setting the config variable "UseFtpProxyServer" to
false, you will then disable the FTP proxy and use the classical HTTP proxy for ftp
requests also. The only way I found to do that was to add a test in proxyForURL before 
the switch statement in ftp.cc.

Maybe this patch will only be useful to me (in which case it is not worthy to commit
it), but I can assure you that it is much nicer to have full FTP file management in
Konqueror through the FTP proxy, than simply having the HTML pages generated by Squid.
At the beginning, I though to have a new slave (highly based on ftp) to handle 
ftpproxy, something like ftpp://ftp.kde.org, but then I realized it was stupid as
a few line of code would add this support to the standard ftp ioslave.

Bye.
Michael.


-- 
------------------------------------------------------------------
Michael Goffioul		IMEC-DESICS-MIRA
e-mail: goffioul@imec.be	(Mixed-Signal and RF Applications)
Tel:    +32/16/28-8510		Kapeldreef, 75
Fax:    +32/16/28-1515		3001 HEVERLEE, BELGIUM
------------------------------------------------------------------
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]