Re: [Bug debuginfod/27277] Describe retrieved files when verbose

["Frank Ch. Eigler" <fche@redhat.com>]

Hi -

> Yes, since the actual download might take a bit, it is nice to see the
> headers at the moment we commit to a server/download. aka here in the
> source:
> 
>   if (vfd >= 0 && !verbose_reported && committed_to >= 0)
>     {
>       bool pnl = (c->default_progressfn_printed_p && vfd == STDERR_FILENO);
>       dprintf (vfd, "%scommitted to url %d\n", pnl ? "\n" : "",
>                committed_to);
>       if (pnl)
>         c->default_progressfn_printed_p = 0;
>       verbose_reported = true;
>     }

One could print it there, but verbose printing is so voluminous and
unstructured that mingling http headers there can only be for a
masochist human's consumption.


> > > Why is X-FILE-SIZE != Content-Length ?
> > 
> > Because Content-Length can be shorter due to compression
> > transfer-encoding.  It's the file size that governs local storage &
> > DEBUGINFOD_MAXSIZE interaction.
> 
> Ah, of course, then it is indeed useful to have both headers.

(... which reminds me, we should document those new headers in the
webapi section of the debuginfod.8 man page ...)


> Yes, I do think there is something there, but imho it is too vague and
> fragile to be useful as is, especially since it depends on what is in
> the cache.

I believe you mean that these headers would only be available for
files fetched anew, not for queries previously cached.  Yeah.  A
person or tool can force a new fetch by using something like
DEBUGINFOD_CACHE_PATH=`mktemp -d`.


> > That in turn would require THREE new API functions or a stateful
> > set_HEAD_mode_and_return_dev_null one and modifying the three main
> > lookup functions.
> 
> Yes, it definitely is more work.

So, is that your suggestion?  We proceed with that sort of thing?


- FChE