From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id D95603858D39 for ; Thu, 8 Sep 2022 11:42:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D95603858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id B85B3300064F; Thu, 8 Sep 2022 13:42:07 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 7457A4024143; Thu, 8 Sep 2022 13:42:07 +0200 (CEST) Message-ID: <3bae0b842ff7b23865ec2bca2b24171c89369764.camel@klomp.org> Subject: Re: [patch git] PR28284 - debuginfod x-debuginfod* header processing From: Mark Wielaard To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org Date: Thu, 08 Sep 2022 13:42:07 +0200 In-Reply-To: <20220906160547.GE13250@redhat.com> References: <20220903001304.GA20286@redhat.com> <20220906160547.GE13250@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Frank, On Tue, 2022-09-06 at 12:05 -0400, Frank Ch. Eigler via Elfutils-devel wrote: > > This looks good, but I think c->winning_headers needs to be > > freed/cleared at the start of debuginfod_query_server. Otherwise if you > > reuse the debuginfod_client and you hit the cache, the user gets the > > headers from the last use of debuginfod_client that did fetch something > > from a server. Which imho is confusing (the headers won't match the > > cached result returned). >=20 > Good point, we don't want an aborted new transfer to retain records > from a previous run, will fix that. Not just a new transfer, but also when we hit the cache before doing a new transfer. Currently when we hit the cache and don't do any transfer the winning_headers will point to the last http transfer which will have nothing to do with the returned (cached) result. Just like we clear client->url early. Thanks, Mark