Can you provide your system configuration, and the returned configuration as seen by libproxy:

proxy xmpp-client://myserfer
proxy https://myserfer

HTTP Connect for bare jabber is currently not supported by libproxy (not support fro any non https:// protocols). Also, be aware that Pidgin erroneously reads the HTTP_PROXY rather then SECURE_PROXY gnome setting for doing HTTP Connect.

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?

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

My account does have the fallback-servers set with oldssl, but does this mean that if it can connect without going through the configured proxy it will do that? 

I am not actually required to use the proxy to connect, but set it up just for testing this bug.  If it just ignores the proxy setting because it can connect without it, my test environment isn't really good for validating this bug.

(In reply to comment #4)
> My account does have the fallback-servers set with oldssl, but does this mean
> that if it can connect without going through the configured proxy it will do
> that? 

With the current implementation, yes.

> 
> I am not actually required to use the proxy to connect, but set it up just for
> testing this bug.  If it just ignores the proxy setting because it can connect
> without it, my test environment isn't really good for validating this bug.

Right, to test it, you need to isolate yourself from the internet. Maybe you can try by disable dns (comment the nameserver lines in resolve.conf) and set your proxy server dns (if you have one) in /etc/hosts. If the proxy is on the same host, well at least you will see the proxy being called even if it fails in the end.

Should I conclude this bug was invalid ?

Created attachment 60534 [details]
All-24-04-12_11-03-19.log

I tried that, with no nameserver set.  Other apps work fine through the proxy, firefox, ubuntuone, etc.  But when connecting with empathy it still doesn't even try to hit the proxy.  I am attaching the log.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org'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.freedesktop.org/telepathy/telepathy-gabble/issues/221.