Currently, checking the existence of a file and gathering its information requires a user to download the file. This can be inconvenient for some users who, for example, are curious to know information on a file before its downloaded. Queries should be supported which allow a user to analyze some information relating to a file without downloading it.
The tricky aspect of this is not so much the webapi, but the C api and the debuginfod-find cli.
A suggested C api was discussed here:
(see also the whole thread in the previous quarter)
/* Get info about an debuginfod artifact. Used to know whether
the target is already in local cache or whether it can be retrieved
from one if the urls contained in $DEBUGINFOD_URLS.
If build_id_len == 0, the build_id is supplied as a lowercase
hexadecimal string; otherwise it is a binary blob of given length.
If the requested resource is in cache, return a file descriptor
which an be used as is. If the requested resource can be found
through one of the DEBUGINFOD_URLS then -1 is returned and
file_size and transfer_size are set to the number of bytes of
the target file and the number if bytes that need to be transferred
from the server (file_size is the uncompressed size, transfer_size
might be the compressed size). Otherwise return -2 to indicate the
requested artifact cannot be found.
If the file wasn't in cache, but can be retrieved from a remote
server, then debuginfod_get_url () will return where the target
can be found. A successive debuginfod_find_* call will retieve
the resource (unless a network error occurs). */
int debuginfod_info_debuginfo (debuginfod_client *client,
const unsigned char *build_id,
size_t *size, size_t *transfer_size);
The problem of federation reminded me that we haven't solved this problem yet.
> int debuginfod_info_debuginfo (debuginfod_client *client,
> const unsigned char *build_id,
> int build_id_len,
> size_t *size, size_t *transfer_size);
It'd also need the other current X-DEBUGINFOD-* response headers, -FILE: and -ARCHIVE:. And we'd need two other functions for source and executable. And if any fields get added at the server by our software (or someone else's proxy!), the API would have to expand to match.
For federation purposes, we'd need to forward all these headers from upstream to downstream. And we'd like to get this data for an active transfer, not really a historical one (don't want to have to save/cache), and not make an extra query to a debuginfod server just to fetch this.
These considerations lead me back to suggesting an API oriented toward fetching the headers of the current/last fetch made with a debuginfod_client, just like the debuginfod_get_url(), returning some subset of what's currently stored by the client code as ->winning_headers. Specifically, I'd say save & return those response headers with prefix "x-debuginfod-".
These ones would be the same ones that a hypothetical "debuginfod-find -d" (describe?) option would want to print to stderr: a more concentrated output than the -v (verbose) firehose we were talking about earlier.