This request is coming from https://bugzilla.redhat.com/show_bug.cgi?id=1318850 (someone trying to use spice-gtk/remote-viewer over an https connection to a proxy and failing to do so).
The gist of it is that when checking the remote-end certificate, glib code only has an IP address available (as this is the only thing g_proxy_address_new() accepts), but the remote end certificate is most likely to provide a DNS name rather than an IP.

From that other bug:
« Dan Winship 2016-04-18 12:31:42 EDT

(In reply to Christophe Fergeau from comment #11)
> 'identity' is GProxyAddress, which derives from GInetSocketAddress so the
> codepath which triggers is in verify_identity_ip(), and the certificate has
> to be valid for the proxy IP rather than its hostname. It seems we have to
> use an IP as this is what is expected by the proxy API in GIO?

Yes... this seems to be a problem with the API design »

and then

«  Dan Winship 2016-04-19 08:34:26 EDT 
> Maybe an additional GProxyNetworkAddress deriving from GNetworkAddress will be > needed.

I haven't spent a ton of time thinking about this, but I think adding more fields to GProxyAddress would probably be better.

(Also, FWIW, note that basically nobody uses http-proxying-via-https, as evidenced by the fact that glib has had proxy support for years without anyone ever running into this problem. And GNOME, Firefox, PAC files, etc, don't let you specify a proxy-via-https. [You can specify an https-specific proxy, but that's an unencrypted proxy that gets used for encrypted connections, not an encrypted proxy that gets used for all connections.] So, maybe using https isn't the right answer here anyway?) »