From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#22745: guix http downloads don't resume Date: Fri, 25 Mar 2016 09:35:12 +0100 Message-ID: <87poujt0ov.fsf@gnu.org> References: <20160220093445.45cd64d2@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajNDx-0007Ol-V6 for bug-guix@gnu.org; Fri, 25 Mar 2016 04:36:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajNDu-0000aq-OH for bug-guix@gnu.org; Fri, 25 Mar 2016 04:36:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:39675) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajNDu-0000aj-Kf for bug-guix@gnu.org; Fri, 25 Mar 2016 04:36:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ajNDu-0006WV-GC for bug-guix@gnu.org; Fri, 25 Mar 2016 04:36:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <20160220093445.45cd64d2@scratchpost.org> (Danny Milosavljevic's message of "Sat, 20 Feb 2016 09:34:45 +0100") 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: Danny Milosavljevic Cc: 22745@debbugs.gnu.org Danny Milosavljevic skribis: > By now, guix reconfigure has tried to download the same texlive binary fr= om hydra at least 5 times to the same machine, unsuccessfully breaking afte= r about 1 GB each, for a total of 5 GB, always starting from the beginning. > > Would it be possible to just resume? There does not seem to be an easy way to achieve this. > Additionally, it doesn't seem like it checks the Content-Length in order = to find out whether the connection broke before the file was done. Why does= n't it? For archives (the /nar/foo URLs), there is currently no =E2=80=98Content-Le= ngth=E2=80=99 header at all (this is because Hydra, the software, generates those files on the fly; we should tweak nginx to add a =E2=80=98Content-Length=E2= =80=99 header, but this seems to require an external nginx plugin.) However, the {mirror.,}hydra.gnu.org use chunked encoding, indeed, which allows the HTTP client to detect truncated transfers. Ludo=E2=80=99.