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

[lilydjwg <lilydjwg@gmail.com>]

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%?

-- 
Best regards,
lilydjwg