Review Request: Fix for connecting to FTP sites through HTTP proxy

[Andreas Hartmetz]

On Wednesday 09 March 2011 23:43:23 Dawit A wrote:
> On Wed, Mar 9, 2011 at 2:53 PM, Andreas Hartmetz <ahartmetz at gmail.com> 
wrote:
> > On Wednesday 09 March 2011 20:06:40 Dawit A wrote:
> >> On Wed, Mar 9, 2011 at 12:46 PM, David Faure <faure at kde.org> wrote:
> >> > On Wednesday 09 March 2011, Dawit Alemayehu wrote:
> >> >> proxiedBy always returns true since ftp.protocol no longer contains a
> >> >> "ProxiedBy=" entry.
> >> > 
> >> > Yes it does, of course. But the point of the additional if() is to not
> >> > go into that code block for other procotols, like HTTP, FISH, and so
> >> > on.
> >> 
> >> I meant to say "always returns false". KProtocolInfo::proxiedBy(...)
> >> always returns an empty string for FTP. I just looked at the log for
> >> ftp.protocol file and it seems that Andreas had mistakenly removed the
> >> "proxiedBy=" statement from the ftp.protocol file. See
> >> 
> >> http://quickgit.kde.org/?p=kdelibs.git&a=commit&h=7b61621c023db80af888a1
> >> 2be 7fcb9fd6c9a6fb8
> >> 
> >> As such the changes the fix I committed current does not fix the
> >> problem. FTP over HTTP proxy still does not work. Anyhow, if the
> >> incorrect commit mentioned above gets reverted, the problem away. Any
> >> objections with me doing that ?
> > 
> > I was thinking proxiedBy= was there to somehow involve the HTTP ioslave
> > in proxied FTP transactions because the HTTP (and SOCKS IIRC) proxy
> > implementation was there.
> 
> Yes, it is, but not for those reasons. That entry was not put there
> simply because we had an HTTP proxy implementation, but because FTP
> requests can be routed through an HTTP proxy server just like HTTP and
> HTTPS requests. IOW, what do you do when the user specifies a HTTP
> proxy server as the FTP proxy. It is legal and valid to do that. What
> is happening in KDE now is that functionality is not supported for
> some unknown reason.
> 
Do you mean CONNECT? CONNECT is implemented in TcpSlaveBase via Qt sockets.
CONNECT is entirely unlike real HTTP proxying (see below), it's very much like 
SOCKS - it's application-level port forwarding and IIRC not even standardized 
in a real Internet standard.
The HTTP ioslave only handles actual HTTP proxying, where you talk HTTP to the 
proxy server and the proxy returns the data as if it was the originating 
server.

I don't see how the HTTP ioslave could help the FTP ioslave somehow unless 
there is some scheme in which the client talks HTTP to the proxy, which talks 
FTP to an FTP server, while the client still says it's FTP to the user / sets 
up the whole thing as described if the user requests FTP and an HTTP proxy is 
set.
If such a scheme exists a one-off hack somewhere would be appropriate.

> > What I gather from this thread is that some HTTP proxies present FTP in
> > HTML format... I think you have to be careful not to break FTP over
> > SOCKS proxy if you make any changes here.
> 
> Since there is no input for specifying SOCKS proxy in the proxy
> configuration dialog, then I assume that the user is supposed to enter
> a non standard url, "socks://<host>:[<port>]", for specifying SOCKS
> proxy, correct ? If so, then ensuring FTP over SOCKS is not treated as
> FTP over HTTP is a simple one line fix in
> KProtocolManager::slaveProtocol.
> 
> BTW, as it stands right now the ftp protocol does not support FTP over
> SOCKS.
> 
SOCKS proxy support should be transparent to ioslaves.
FTP has the unique problem that it needs two ports to work, but TCPSlaveBase 
only allows one network connection per ioslave.
I think this should be solved by using a KTcpSocket for the data connection, 
if necessary with manual tweaks to use the right proxy settings, in the FTP 
ioslave code.
Passive FTP only, active would require asking the proxy to open a port etc., 
way too ugly. Passive has become the usual way to do FTP.

> > proxiedBy should probably be per proxy protocol now.
> 
> Sorry, but that would only serve to complicate proxy handling much
> more than the big mess it already is.
> 
It's not that messy: network-level proxies are handled by TcpSlaveBase, 
application protocol-level proxying (of which there is only HTTP) is 
implemented in protocol ioslaves.

After writing the above questions and answers I think proxiedBy should stay 
dead.