[Bug 47960] gabble not using system defined proxy

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47960

--- Comment #3 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2012-03-28 12:30:14 PDT ---
(In reply to comment #2)
> proxy xmpp-client://myserfer
> direct://
> proxy https://myserfer
> http://localhost:3128
> 
> Looking through the gabble source, I don't see anywhere that it uses libproxy,
> not even an includes for proxy.h.  How does it interact with libproxy?
> 
> Previously it had been suggested that it wasn't working because our version of
> libproxy in Ubuntu was too old, 0.3.x.  We now have the 0.4.7, the latest and
> it still doesn't work.
> 
> So this isn't a bug so much as it is not supported yet?

Gabble uses a library called Wocky which is base on GIO. And GIO has a libproxy
and gnome plugin. I usually suggest using libproxy for distro that can run both
KDE and Gnome on the same install, the Gnome plugin ignores the environment.

Currently the support for HTTP Connect is very restricted because the GIO
developers did not agree it was a correct way of doing generic socket proxying.
Here is how you can make it work. First thing to know is that wocky will do
HTTP Connect only when you are running in Old SSL mode. Which mean the first
thing you do is an TLS handshake (so it cannot be differentiated from a HTTPS
connection). Then you need a correct configuration, which you have.

If you are using a google account configured with older version of Empathy, I
suggest to remove it and re-create it. This will add the fallback-servers
parameter to your account. Note that HTTP Connect is never the first, so
connection may take a little while depending on how fat the other attempts
fails. You can check the params using mc-tool show ... Here's what you should
see:
(GStrv) fallback-servers = ["talkx.l.google.com",
"talkx.l.google.com:443,oldssl", "talkx.l.google.com:80"]

Unless someone broke the fallbacks, wocky will try the server talk.google.com
(use to do SRV, but was changed recently). In case of failure, it will fallback
to talkx.l.google.com using normal TLS, if it fails again, it will try
talkx.l.google.com:443 using OLD SSL mode, and if that still fails it will try
cleartext on port 80 (I think this one always fails these days, not sure).

In the future, libproxy should try HTTP Connect for any type of connection, and
have a direct fallback, but that couldn't be done without changing libproxy
internals a lot. Also, the HTTP Connect GLIB plugin should be provided by
libsoup. Feel free to contribute if you have time.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.