Bug 28284 - support description functionality through HEAD
Summary: support description functionality through HEAD
Status: NEW
Alias: None
Product: elfutils
Classification: Unclassified
Component: debuginfod (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Noah Sanci
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-08-27 19:02 UTC by Noah Sanci
Modified: 2022-01-20 00:17 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Noah Sanci 2021-08-27 19:02:48 UTC
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.
Comment 1 Frank Ch. Eigler 2021-08-27 19:05:41 UTC
The tricky aspect of this is not so much the webapi, but the C api and the debuginfod-find cli.
Comment 2 Mark Wielaard 2021-11-10 14:17:12 UTC
A suggested C api was discussed here:
https://sourceware.org/pipermail/elfutils-devel/2021q4/004239.html
(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,
                               int build_id_len,
                               size_t *size, size_t *transfer_size);
Comment 3 Frank Ch. Eigler 2022-01-20 00:17:45 UTC
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.