[Bug debuginfod/27277] Describe retrieved files when verbose

[Frank Ch. Eigler]

Hi -

> [...]
> And if I understand your comments above correctly, you would rather see
> a function like const char* debuginfod_get_url (debuginfod_client
> *client); but for any headers. 

Correct.

> Would such a headers call be only be accessible during
> debuginfod_progressfn_t callback or would it retain the headers so
> they can be found after a debuginfod_find_* call (as long as
> debuginfod_end hasn't been called on the client handle)?

Like _url(), it'd would persist the value until the client is deleted.


> Personally I don't really like an interface that relies on the program
> having to parse somewhat arbitrary strings. I can see how it is useful
> in verbose mode for the user to see the headers to know what is going
> on (which we have now). 

The problem with what we have now, with $DEBUGINFOD_VERBOSE, is that
the amount of output is huge.  It is a debugging level trace.  It's
not consumable by non-expert users OR by software.

> But if the program needs to make any policy decisions then what do
> we guarantee about the provided header strings?

The simplest thing to do is simply to save whatever we fetched and
present it verbatim.  Parsing one-line "key: value" HTTP headers is
not that difficult.  We could -add- a few headers in order to provide
guarantees, but that's not necessary.  (We should catch up with
documenting the headers that debuginfod is known to send.)

But "programs making policy decisions" is not the only use case: what
about where a user would like to get a glance at that metadata, and
not all the other $DEBUGINFOD_VERBOSE firehose?  They could ALMOST do
it themselves via "% curl -I -i $URL", except $URL is synthesized and
competitively tie-broken between $DEBUGINFOD_URLS.


- FChE