From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id D40633848409 for ; Fri, 6 Aug 2021 18:55:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D40633848409 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-195-5I8cZDNEOii35_VAOomoaA-1; Fri, 06 Aug 2021 14:55:02 -0400 X-MC-Unique: 5I8cZDNEOii35_VAOomoaA-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 5CFEF801AC0; Fri, 6 Aug 2021 18:55:01 +0000 (UTC) Received: from redhat.com (ovpn-112-63.phx2.redhat.com [10.3.112.63]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3FD1A1B4B8; Fri, 6 Aug 2021 18:55:01 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.94.2) (envelope-from ) id 1mC4zj-0007rB-LQ; Fri, 06 Aug 2021 14:54:59 -0400 Date: Fri, 6 Aug 2021 14:54:59 -0400 From: "Frank Ch. Eigler" To: Mark Wielaard Cc: Noah Sanci , elfutils-devel@sourceware.org Subject: Re: [Bug debuginfod/27277] Describe retrieved files when verbose Message-ID: <20210806185459.GE4195@redhat.com> References: <20210805165402.GD4195@redhat.com> <35f2073dfeed8f008d42a78bf60b7efcf13164eb.camel@klomp.org> MIME-Version: 1.0 In-Reply-To: <35f2073dfeed8f008d42a78bf60b7efcf13164eb.camel@klomp.org> User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 18:55:05 -0000 Hi - > Yes, since the actual download might take a bit, it is nice to see the > headers at the moment we commit to a server/download. aka here in the > source: > > if (vfd >= 0 && !verbose_reported && committed_to >= 0) > { > bool pnl = (c->default_progressfn_printed_p && vfd == STDERR_FILENO); > dprintf (vfd, "%scommitted to url %d\n", pnl ? "\n" : "", > committed_to); > if (pnl) > c->default_progressfn_printed_p = 0; > verbose_reported = true; > } One could print it there, but verbose printing is so voluminous and unstructured that mingling http headers there can only be for a masochist human's consumption. > > > Why is X-FILE-SIZE != Content-Length ? > > > > Because Content-Length can be shorter due to compression > > transfer-encoding. It's the file size that governs local storage & > > DEBUGINFOD_MAXSIZE interaction. > > Ah, of course, then it is indeed useful to have both headers. (... which reminds me, we should document those new headers in the webapi section of the debuginfod.8 man page ...) > Yes, I do think there is something there, but imho it is too vague and > fragile to be useful as is, especially since it depends on what is in > the cache. I believe you mean that these headers would only be available for files fetched anew, not for queries previously cached. Yeah. A person or tool can force a new fetch by using something like DEBUGINFOD_CACHE_PATH=`mktemp -d`. > > That in turn would require THREE new API functions or a stateful > > set_HEAD_mode_and_return_dev_null one and modifying the three main > > lookup functions. > > Yes, it definitely is more work. So, is that your suggestion? We proceed with that sort of thing? - FChE