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
