I am attempting to use guix from within a network that does not allow outbound http connections except via an http proxy. I am using Guile v2.0.11, which supports http proxies, so my expectation would be that since I have http_proxy and https_proxy environment variables set, guix would use the specified proxy for outbound http connections, but instead it appears to ignore the proxy settings and attempts to contact the http server directly, which results in a timeout.
For example, when doing a `guix pull` I got the following:
$ guix pull
ERROR: In procedure connect: Connection timed out
guix pull: error: failed to download up-to-date source, exiting
It appears that Guile has had support for http proxies in the web client package since v2.0.10, and although guix is using the http-get method from Guile, it isn't using the open-socket-for-uri method, which is the one that implements making a proxy connection. Instead, guix seems to have copied and modified the code from an older version of open-socket-for-uri into open-connection-for-uri (http://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/download.scm?id=v0.8.1#n153) and uses that instead. I suspect what has happened is that the Guile version of open-socket-for-uri has added proxy support since the code was copied into open-connection-for-uri. One fix would be to port over the changes to open-socket-for-uri that were made in Guile 2.0.10.
However, it appears from the code comment that that the reason open-connection-for-uri copies the functionality of open-socket-for-uri is to avoid NSS lookups for symbolic port arguments, and it looks to me that since version 2.0.7 of Guile, its open-socket-for-uri can be convinced not to do NSS lookups as long as (uri-port uri) is not #f (see http://git.savannah.gnu.org/cgit/guile.git/tree/module/web/client.scm?id=v2.0.7#n53).
Rather than porting the new code from Guile's open-socket-for-uri, it might make more sense to just call open-socket-for-uri with a uri that always has a port (i.e. implement the same hard-coding for http and https in the http-fetch function to make sure that uri has the default port set - I notice for some reason Guile's string->uri parser does not set the port for http and https even though it has the default ports for both set in the code. I suppose one could use the existing post-2.0.7? test to keep calling open-connection-for-uri for backwards compatibility with old versions of Guile (which in any case don't have proxy support, so for my use case it doesn't matter).
I can try to put together a patch that implements this fix, although I haven't written scheme in quite a while, so someone else may be better suited for it.