GNOME Bugzilla – Bug 724316
SoupConnection: SoupAddress protocol left unset
Last modified: 2015-04-08 06:58:58 UTC
I'm currently at eds commit cc85b40, evo commit 0d52e31 and ews commit 0e01d38 and I just realized that the EWS account doesn't honour proxy settings from evolution. I know it. because if I fill the same https proxy in 3.10.3, then EWS cannot connect to the server, while without it it can. What I have: a) Edit->Preferences->Network Preferences->Default proxy settings Method: [ Manual ] HTTP Proxy: [ <empty> ] HTTPS Proxy: [ my.example.proxy.com ] [ 3128 ] Socks Proxy: [ <empty> ] Ignore hosts: [ <empty> ] b) run evolution with EWS_DEBUG=2 and see how the evolution-ews can connect to its server without any issue, while my proxy forbids connection to it. It's proven by 3.10.3 with the exact same settings, which cannot connect. I fill it under evolution, because I suspect more places are affected.
Break on e_source_proxy_lookup() and check if the URI for the Exchange server starts with "http://" and not "https://". That's what I'm seeing, and I think that's the issue. I don't know where the "http://" URI is coming from, though. Whether evolution-ews is building it or libsoup is building it. The machinery at the EDS layer seems to be working okay, so reassigning to evolution-ews.
I traced the problem to libsoup. If I break on soup_connection_connect_async(), I see the SoupConnection's "remote_uri" has "https" for its scheme. But this gets lost when creating a SoupAddress as the protocol is never set, only host and port. Here's where I'm looking: https://git.gnome.org/browse/libsoup/tree/libsoup/soup-connection.c#n520 If I then break on soup_address_connectable_proxy_enumerate(), the code there assumes "http" because the SoupAddress's protocol is not set. Here's where I'm looking: https://git.gnome.org/browse/libsoup/tree/libsoup/soup-address.c#n1244 Your example config didn't specify an HTTP proxy, only HTTPS. And the proxy resolver is receiving an "http://" URI, so it's correctly resolving that to a "direct://" proxy URI. Dan would know better, but it seems like either the SoupAddress's protocol should be explicitly set to ensure correct proxy resolution, or else proxy_enumerate() should peek at the port number and guess either "http" or "https" (though this seems more hackish to me).
Created attachment 269418 [details] [review] Proposed patch This makes Milan's test case work. With the bogus proxy address, the proxy resolver now receives an "https" URI and I get the expected error in Evolution: "Error resolving 'my.example.proxy.com': Name or service not known".
Created attachment 269420 [details] [review] Proposed patch This makes Milan's test case work. With the bogus proxy address, the proxy resolver now receives an "https" URI and I get the expected error in Evolution: "Error resolving 'my.example.proxy.com': Name or service not known".
Sorry for the double post... bugzilla was stalling on me again.
thanks, committed and it will go out in the release later today
*** Bug 738417 has been marked as a duplicate of this bug. ***
*** Bug 726960 has been marked as a duplicate of this bug. ***