FROM A LAUNCHPAD BUG There seems to be no way to connect to MSN through another method than using port 1863. In some environments, ports other than, for example, 80 and 443 are not allowed to egress. Users then commonly try to use gateway.messenger.msn.com over port 80 (or is it 443)? This is behavior that is already implemented in Pidgin, as well as the official MSN clients.
Created attachment 27953 [details] [review] patch This is a quick patch, not even tested
The ideal scenario would be that we don't have to expose that property to the user. tp-butterfly should auto-magically use the gateway if necessary.
Did someone test this patch on a HTTP only connection? My connection lets me use the MSN port so I can't
I attempted the patch but I realized I have additional requirements. It needs to go through a HTTP proxy with authentication on the HTTP proxy. I have the Gnome system proxy set up but I could not find where to set it up in Empathy.
Created attachment 31006 [details] [review] fallback to http automatically Inspired by Laurent's patch and Louis-Francis' indications... Here's a patch that tries a connection to the server and port specified in the user's settings, and if it doesn't connect within 10 seconds, falls back to an HTTP connection. / Matt
Hi Matt, Sorry for the wait, I took a look at your patch and it looks good but we would rather not have a separate test connection but use the http method if the normal one fail, do you think you can make that adjustement? Also where the code test if proxy is None, in the else you should set use_http_method to True since it make sense if you have a http proxy to use the HTTP method. Regards, Olivier
Olivier, sorry I didn't respond any sooner I had only seen the comment on Launchpad. I certainly can make the change. I had opted to use a separate test because it does cause one to wait substancially less for the standard connection to fail (since you can wait a long time if a firewall just drops packets rather than sending an ICMP reply). I however know that the test itself was kind of poorly done, with an arbitrary timeout... Thanks for the response about using the HTTP transport by default for proxy connections, it does make sense. That said, I'd then also remove "proxies" from the standard connection since it would always be empty in that case. / Matt
*** Bug 20452 has been marked as a duplicate of this bug. ***
It would be nice to not need a property to use HTTP and just automatically use it when we can't use the 1863, but the direct connection takes too long to time out, so perhaps we should also have a "use-http-connection" property to force the behaiviour?
I implemented this: http://git.collabora.co.uk/?p=user/jonny/telepathy-butterfly.git;a=shortlog;h=refs/heads/http I added a "use-http" parameter (using that name to be consistent with haze's MSN parameter) to force using an HTTP connection so if users know 1863 won't work, they can avoid the long timeout delay. I played with my router (no doubt annoying my housemates) and it all appears to work with appropriate ports blocked. Another one for you to review, Olivier!
can't test is here but the code is ok
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.