From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 685A43857C56 for ; Wed, 29 Sep 2021 21:28:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 685A43857C56 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-483-Y6dBABuDPz6Wth06NZFg8Q-1; Wed, 29 Sep 2021 17:28:53 -0400 X-MC-Unique: Y6dBABuDPz6Wth06NZFg8Q-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6B51818125C8; Wed, 29 Sep 2021 21:28:51 +0000 (UTC) Received: from redhat.com (ovpn-112-152.phx2.redhat.com [10.3.112.152]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 218C56A916; Wed, 29 Sep 2021 21:28:51 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.94.2) (envelope-from ) id 1mVh8C-0003GB-2W; Wed, 29 Sep 2021 17:28:48 -0400 Date: Wed, 29 Sep 2021 17:28:47 -0400 From: "Frank Ch. Eigler" To: Mark Wielaard Cc: elfutils-devel@sourceware.org Subject: Re: [Bug debuginfod/27277] Describe retrieved files when verbose Message-ID: <20210929212847.GA11484@redhat.com> References: <20210805165402.GD4195@redhat.com> <35f2073dfeed8f008d42a78bf60b7efcf13164eb.camel@klomp.org> <20210806185459.GE4195@redhat.com> <9ac621fee207ef233873c40843b3d34ced9019cc.camel@klomp.org> <20210922203331.GC13236@redhat.com> <599234fd5a36629b580d0a615ac069835295111f.camel@klomp.org> MIME-Version: 1.0 In-Reply-To: <599234fd5a36629b580d0a615ac069835295111f.camel@klomp.org> User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2021 21:28:57 -0000 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