From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joshua Randall Subject: bug#20402: guix cannot download via an http proxy Date: Tue, 21 Apr 2015 23:56:02 +0100 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1134788c618db6051443f3be Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkhAA-0002eS-C4 for bug-guix@gnu.org; Tue, 21 Apr 2015 19:01:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkhA6-00024r-AV for bug-guix@gnu.org; Tue, 21 Apr 2015 19:01:06 -0400 Received: from debbugs.gnu.org ([140.186.70.43]:45830) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkhA6-00024n-7L for bug-guix@gnu.org; Tue, 21 Apr 2015 19:01:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YkhA6-0005cJ-2Y for bug-guix@gnu.org; Tue, 21 Apr 2015 19:01:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org To: 20402@debbugs.gnu.org --001a1134788c618db6051443f3be Content-Type: text/plain; charset=UTF-8 Package: guix Version: 0.8.1 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 starting download of `/tmp/guix-file.l1zwZ7' from ` http://git.savannah.gnu.org/cgit/guix.git/snapshot/guix-master.tar.gz'... ERROR: In procedure connect: Connection timed out failed to download "/tmp/guix-file.l1zwZ7" from " http://git.savannah.gnu.org/cgit/guix.git/snapshot/guix-master.tar.gz" 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. Cheers, Josh. --001a1134788c618db6051443f3be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Package: guix
Version: 0.8.1

= I am attempting to use guix from within a network that does not allow outbo= und http connections except via an http proxy. I am using Guile v2.0.11, wh= ich supports http proxies, so my expectation would be that since I have htt= p_proxy and https_proxy environment variables set, guix would use the speci= fied 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 `g= uix pull` I got the following:=C2=A0
$ guix pull
s= tarting download of `/tmp/guix-file.l1zwZ7' from `http://g= it.savannah.gnu.org/cgit/guix.git/snapshot/guix-master.tar.gz'...
ERROR: In procedure connect: Connection timed out
failed= to download "/tmp/guix-file.l1zwZ7" from "http://git= .savannah.gnu.org/cgit/guix.git/snapshot/guix-master.tar.gz"
=
guix pull: error: failed to download up-to-date source, exiting
<= /div>

It appears that Guile has had support for http pro= xies in the web client package since v2.0.10, and although guix is using th= e http-get method from Guile, it isn't using the open-socket-for-uri me= thod, 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 op= en-socket-for-uri into open-connection-for= -uri (http://git.sa= vannah.gnu.org/cgit/guix.git/tree/guix/build/download.scm?id=3Dv0.8.1#n153<= /a>) and uses that instead. I suspect what has happened is that the Guile v= ersion of open-socket-for-uri has added proxy support since the code was co= pied into open-connection-for-uri. One fix would be to port over the change= s to open-socket-for-uri that were made in Guile 2.0.10.=C2=A0
=


Rather than = porting the new code from Guile's open-socket-for-uri, it might make mo= re 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 an= d https even though it has the default ports for both set in the code. I su= ppose one could use the existing=C2=A0post-2.0.7? test to keep calling open-connection-for-uri for backwards c= ompatibility with old versions of Guile (which in any case don't have p= roxy support, so for my use case it doesn't matter).
<= span style=3D"color:rgb(0,0,0)">
I can try to put together a patch that implements this fix, alt= hough I haven't written scheme in quite a while, so someone else may be= better suited for it.=C2=A0

Cheers,

Josh.

--001a1134788c618db6051443f3be--