Hi Frank,
On Fri, 2021-08-06 at 14:54 -0400, Frank Ch. Eigler wrote:
> > 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.
But the verbose output up to now is also chronological. I would expect
the headers to be shown before seeing verbose traces of other activity.
> > 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`.
Which IMHO is not a great interface, especially if it forces a full new
download.
> 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?
Yes, separate the verbose printing of http headers (which I really do
like) from providing an interface to query what needs to be done to get
some file (is it in cache, can it be retieved from a remote server, how
big is it?) I don't think providing raw http headers is that interface.
Cheers,
Mark
