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
