Hi - > > Hey, great idea actually tallying up writes in the callback function. > > (We need to take care to clear that counter, in case of client object > > reuse.) Also, can you think of some reason not to just use that value > > at all times, i.e., without any of that "if and only if ..." business? > > The counter is in handle_data, and it is already cleared at > "query_in_parallel:". I don't find other places that may reuse them.
OK. > 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. - FChE
