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
