Re: [PATCH v2 2/2] debuginfod-client.c: Fix x-debuginfod-size counts differently than CURLINFO_SIZE_DOWNLOAD_T

[Mark Wielaard <mark@klomp.org>]

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.
> > 
> > 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%.
> > 
> > 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.
> 
> 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).
> 
> 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