From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web11.8061.1595603379494023984 for ; Fri, 24 Jul 2020 08:09:39 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PtcI9pVe; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1595603378; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mV0l8Fy0E3MHZtCNy4CCbo9C76BzPP8wfKB5tDqyleE=; b=PtcI9pVeJupVyh6fo+2QE4Pj3txFDUdZkJltWBmPBQUSk9ZHr1PsSZ+4n2jQhIzk+BAUPv DHdAXvm6keN5bBifQZLnosMQUFt9lHo9j2ZYDATX3qM2WFWHa9ifLjb13gfz7pCC02TJHb gV4GQhl7Hmfoh/pl2zl9evGnRAJ20Kk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-432-ClzFA0cNM3KFeC0vy0PuYg-1; Fri, 24 Jul 2020 11:09:34 -0400 X-MC-Unique: ClzFA0cNM3KFeC0vy0PuYg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A718B91274; Fri, 24 Jul 2020 15:09:32 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-113.ams2.redhat.com [10.36.112.113]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1F40E79D01; Fri, 24 Jul 2020 15:09:29 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v3 1/1] ShellPkg/DynamicCommand: add HttpDynamicCommand To: Vladimir Olovyannikov , devel@edk2.groups.io Cc: Samer El-Haj-Mahmoud , Zhichao Gao , Maciej Rabeda , Jiaxin Wu , Siyuan Fu , Ray Ni , Liming Gao , Nd References: <20200713183137.9825-1-vladimir.olovyannikov@broadcom.com> <6b8ae026-a39c-3b68-4280-fc532b5954d6@redhat.com> <8de76fe2aa9ca0f8ab45fe8245428453@mail.gmail.com> From: "Laszlo Ersek" Message-ID: <20cc1951-cd4e-a9d5-a24a-96f273002bed@redhat.com> Date: Fri, 24 Jul 2020 17:09:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <8de76fe2aa9ca0f8ab45fe8245428453@mail.gmail.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 07/23/20 19:18, Vladimir Olovyannikov wrote: >>> One suggestion: if the download fails for some reason, but the local >>> file creation succeeded, then upon exit, the local file should be >>> deleted. Otherwise an incomplete (possibly zero size) file is left in >>> the filesystem. > I was thinking about this. > Sometimes, an error file returned by HTTP server (say, on 404 or 503) has > more information than just 404, 503, etc. > That was the only reason I do not delete it. > I still return error code to the caller, so the caller can read it (maybe, > to provide more information to the user), and/or delete it right away. > What do you think? Seems unusual to me; at least I'm not used to it with "wget". I seem to remember that, whenever I get a 404 or 503 with wget, I don't have to clean up after wget. With a graphical web browser, things are different, in that case, rendering the textual (HTML etc) response can be helpful. If you decide to keep the local files in such cases (i.e., on failure), I suggest documenting that fact in the built-in help text. Thanks! Laszlo