GNOME Bugzilla – Bug 524532
No proxy support
Last modified: 2018-09-21 16:20:19 UTC
The FTP backend doesn't seem to handle proxies. It should use libproxy: http://code.google.com/p/libproxy/ like libsoup does (or will do, bug 502103)
I dont think every backend should write its own logic. I also looked at libproxy and I dont think we should use it since it doesnt give us that much. Its a basically a abstraction lib that is not really necessary. The only interesting bit would be the PAC support but I looked at that, and its not much since libproxy basically just uses mozilla's java script library to implement PAC. We could just re-implement that since its really not that much code.
Since gvfsd-ftp uses libsoup for connections we'll hopefully gain proxy support for free. Although special care is needed for proxying ftp connections if the ftp client operates in Active mode, which gvfsd-ftp doesn't yet support (see bug 516704).
SoupProxyResolver works in terms of SoupMessages (which are http-specific), so gvfsd-ftp wouldn't be able to use it. However, we could make it work in terms of SoupURI instead. (I have to redo the API to make it work with proxy authentication anyway.) I don't think proxying is expected to be compatible with active mode, though I'm not really familiar with the proxying situation under ftp...
(In reply to comment #3) > SoupProxyResolver works in terms of SoupMessages (which are http-specific), so > gvfsd-ftp wouldn't be able to use it. However, we could make it work in terms > of SoupURI instead. (I have to redo the API to make it work with proxy > authentication anyway.) Ok, I'll have to investigate this.... (There's no such thing as a free lunch.) > > I don't think proxying is expected to be compatible with active mode, though > I'm not really familiar with the proxying situation under ftp... > No it's not expected... Active mode proxying is completely FTP-specific. The main issue is that the FTP protocol is broken and sends ip-addresses in the application layer. A PORT command (used by client in active mode) includes the ip-address of the client (as well as port number), telling the server where to connect back the data channel to.... When using a proxy, the client needs to make sure to send the address of the proxy (and not it's own ip address) is sent in the PORT command... (the client also needs to be able to ask the proxy to listen for incoming connections.) Fortunately this layering violation has been fixed in EPRT, but not all server software supports this new extension.
now that we use gnio, what's the state of proxy support there?
gnio has no proxy support yet (see bug 580341) (libsoup master now has SoupProxyURIResolver along the lines of what I said in comment #3, although I forgot to update SoupProxyResolverGNOME to deal with the possibility of non-http URIs, so it won't actually work for you yet.)
noticed this bug while looking for something else... first, change this line in gvfsbackendftp.c: ftp->addr = g_network_address_new (host, port); to ftp->addr = g_object_new (G_TYPE_NETWORK_ADDRESS, "scheme", "ftp", "host", host, "port", port, NULL); which tells GSocketClient to look up ftp-specific proxy settings. GSocketClient internally only handles SOCKS proxies; you'll need to call g_socket_client_add_application_proxy(client, "ftp") to tell it that if libproxy returns a proxy URI of "ftp://...", that you know how to handle that yourself. Then after connecting, check the remote-address of the returned GSocketConnection, and if it's a GProxyAddress and g_proxy_address_get_protocol() returns "ftp", then that means you're connected to a proxy, and you need to do whatever negotiation protocol it is that one does for ftp proxies.
I see that the ftp backend supports SOCKS proxies just fine now.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/45.