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
