Bug 28284

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:
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);

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.

*** Bug 29469 has been marked as a duplicate of this bug. ***

commit 8760e931abf33ed2b215809d5ebf653ced934152
Author: Frank Ch. Eigler <fche@redhat.com>
Date:   Fri Sep 2 12:41:38 2022 -0400

    PR28284: add tweaks on previous debuginfod x-debuginfod* header forwarding work
    
    Embrace case-independent headers, more fully document, handle HTTP \r.
    In addition to test case, hand-tested against fedora debuginfod
    instances, running federated servers under valgrind.
    
    Signed-off-by: Frank Ch. Eigler <fche@redhat.com>

commit bbc2ca6d553f0ce3e670303ac9a3c764cf10d779
Author: Noah Sanci <nsanci@redhat.com>
Date:   Wed Jun 15 10:07:29 2022 -0400

    PR28284 - Debuginfod header functionality implemented
    
    Debuginfod and debuginfod clients are now equipped to send
    and receive http headers prefixed with X-DEBUGINFOD and
    print them in verbose mode for more context
    
    Signed-off-by: Noah Sanci <nsanci@redhat.com>