From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id vx5fBK15lV+vOwAA0tVLHw (envelope-from ) for ; Sun, 25 Oct 2020 13:12:13 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 5bYxO6x5lV+bbAAAB5/wlQ (envelope-from ) for ; Sun, 25 Oct 2020 13:12:12 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 6E7879403E8 for ; Sun, 25 Oct 2020 13:12:12 +0000 (UTC) Received: from localhost ([::1]:60990 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kWfog-00073r-L2 for larch@yhetil.org; Sun, 25 Oct 2020 09:12:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40412) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kWfoY-00073K-Oi for guix-patches@gnu.org; Sun, 25 Oct 2020 09:12:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:52634) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kWfoY-00027c-FG for guix-patches@gnu.org; Sun, 25 Oct 2020 09:12:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kWfoY-00018s-A9 for guix-patches@gnu.org; Sun, 25 Oct 2020 09:12:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#44193] [PATCH 0/1] 'guix publish --cache' can publish items not yet cached Resent-From: Miguel =?UTF-8?Q?=C3=81ngel?= Arruga Vivas Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sun, 25 Oct 2020 13:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44193 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 44193@debbugs.gnu.org Received: via spool by 44193-submit@debbugs.gnu.org id=B44193.16036315084366 (code B ref 44193); Sun, 25 Oct 2020 13:12:02 +0000 Received: (at 44193) by debbugs.gnu.org; 25 Oct 2020 13:11:48 +0000 Received: from localhost ([127.0.0.1]:35947 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kWfoJ-00018M-N3 for submit@debbugs.gnu.org; Sun, 25 Oct 2020 09:11:48 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:34455) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kWfoH-000181-Gf for 44193@debbugs.gnu.org; Sun, 25 Oct 2020 09:11:46 -0400 Received: by mail-wr1-f65.google.com with SMTP id i1so9490722wro.1 for <44193@debbugs.gnu.org>; Sun, 25 Oct 2020 06:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=kR3e8215gWcQXDbjaw9OvKf+RxxgDA49hiJPCQT4vMY=; b=GbDRLro1ahL30K1rJHMkfigmbGHOjyGfyqv0fIHK5TBwEp0Oc2poPpQ6M4oAhtQ1bL pxCAEq27pb6eoCFUnFQFNExYNJDe5cHQuJWiRxNiUNIuqT+pCDE2UBia6EyY+2u74sqN WNTHGEL6YIL/QV7jPICGhfALrdSIzRQcoVHXCm7BqPpl8SiF9EVoLmEZB+C48XvGmhQ8 yl2lZcnnu/nctx9pZ+jFPmXg6ahXBASOMkcDRNTivtL+rC3ev9qe0gC1KlPozfIe1Di8 r44DvZ8rCgOC9C1sUePrt1daOUi4ADu5oXsigd2g4VtHfBoqjiehKwxgok1O/XTdzDW8 Q5Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=kR3e8215gWcQXDbjaw9OvKf+RxxgDA49hiJPCQT4vMY=; b=ff5rQa/jKlwcsJZtcrJCRxEPNOadqwXYcYD7vmPHhdMyqireP2GxyOCiKnCWcwVaCu oilSU26pbMueQLB9zybsMWZk8gNm6cxfnrmkH3su25o5MC8b/2iMDGhY5mxyAq+aTTgh 5uHzeEwB6n7VHFNoo2NbW+Sd3avOhTvnh0j0O53k9wNSFWl9tQiCLQxr24oZqqPPk9pF C9IsvyJUffFWp0kNf9A/C+4xwLQFr1O/XZs+0pnw8mpO3cfqeyANUZKrdupDf2zge4tf ZLMP8BtU3QAOWG+gxKvQjTFZiNBHDZzmNcokkYXCOkcOmv80UQc3vilXxOc7rHwo17Aq K1xA== X-Gm-Message-State: AOAM533koh9wMP5RngGAHIIfvEVQOojWHGUg2JM9tjvHmz5BYW/vDtOz eZrQBYfYf/dYxAVVVTJpIFVqMGithTGJzw== X-Google-Smtp-Source: ABdhPJzFIf2KaohsB4qRqvSd+JSOq3g2px9P8PrJk8Vm972XrcyPz1WxGuPlrj02pr29VBMl/5+MAQ== X-Received: by 2002:adf:d849:: with SMTP id k9mr12248752wrl.332.1603631499408; Sun, 25 Oct 2020 06:11:39 -0700 (PDT) Received: from unfall (218.139.134.37.dynamic.jazztel.es. [37.134.139.218]) by smtp.gmail.com with ESMTPSA id w83sm16697255wmg.48.2020.10.25.06.11.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Oct 2020 06:11:38 -0700 (PDT) From: Miguel =?UTF-8?Q?=C3=81ngel?= Arruga Vivas References: <20201024144929.4529-1-ludo@gnu.org> Date: Sun, 25 Oct 2020 14:11:37 +0100 In-Reply-To: <20201024144929.4529-1-ludo@gnu.org> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Sat, 24 Oct 2020 16:49:29 +0200") Message-ID: <87v9ey5u2e.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -0.8 (/) X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=GbDRLro1; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Spam-Score: 0.09 X-TUID: NqJ7VsqGlAlc Hi! Just one general comment about this issue: Ludovic Court=C3=A8s writes: > Thus, the first narinfo request for an item would always return 404; > one would have to wait until the item is baked to get 200 and download > the substitute. I'd argue that returning unconditionally the 404 is a problem. If the nar is getting baked, I guess that a 202[1] would be the appropriate answer, and I'd leave the 404 for invalid store paths[2]. This way the client could implement more policies: the classic timeout, but also, for example, it might check other servers before checking once again if nobody else has it, or directly wait until a 404 is reached. WDYT? Happy hacking! Miguel [1] Section 10.2.3 from https://www.ietf.org/rfc/rfc2616.txt [2] I understand that it isn't at all a bad usage of the 404, as it explicitly says that the condition might be temporary, but on the other hand I don't know how could that extra information be used by a rogue client in any way worse than it could do right now, as the server process is doing the same computation more or less in both cases.