> 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 <<