From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id A9C9E3858D20 for ; Tue, 29 Aug 2023 13:17:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A9C9E3858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from r6.localdomain (82-217-174-174.cable.dynamic.v4.ziggo.nl [82.217.174.174]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 1ED033000593; Tue, 29 Aug 2023 15:17:37 +0200 (CEST) Received: by r6.localdomain (Postfix, from userid 1000) id 19CE83403B9; Tue, 29 Aug 2023 15:17:35 +0200 (CEST) Message-ID: Subject: Re: [PATCH v2 2/2] debuginfod-client.c: Fix x-debuginfod-size counts differently than CURLINFO_SIZE_DOWNLOAD_T From: Mark Wielaard To: lilydjwg , "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org Date: Tue, 29 Aug 2023 15:17:35 +0200 In-Reply-To: References: <20230329150237.896092-1-lilydjwg@gmail.com> <20230329150237.896092-2-lilydjwg@gmail.com> <20230329191443.GB30778@redhat.com> <20230330172413.GG30778@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 X-Spam-Status: No, score=-3027.5 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, On Fri, 2023-03-31 at 12:50 +0800, lilydjwg via Elfutils-devel wrote: > On Thu, Mar 30, 2023 at 01:24:13PM -0400, Frank Ch. Eigler wrote: > > > The written_size is actual file size (uncompressed), but IIUC > > > Content-Length is the compressed size if Content-Encoding says the > > > content is compressed. I haven't seen any compressed responses with > > > Content-Length, but from the spec I don't read they are not allowed. > >=20 > > OK, so to spell out the hypothetical problem: what if a httpd server > > does send back a Content-Length: response header for a compressed > > file, and we use that as the denominator for progress reporting. If > > we use the decompressed actual file length as numerator, we'd go over > > 100%. > >=20 > > Then ISTM a simpler way to handle this would be to say that if the > > x-debuginfod-size: response header is found (as denominator), then go > > ahead and use the actual data[committed_to].written_size (as > > numerator). Don't even try the CURLINFO_SIZE* queries then. >=20 > It's not tried in that case. size_compressed indicates where the total > size is from and those CURLINFO_SIZE* is skipped. Maybe I should rename > the variable to something else (it's not always compressed). >=20 > Or do you mean that you want to always use written_size even when the > progress may go beyond 100%? What is the status of this patch/discussion? Thanks, Mark