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 [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 9779E3858D37 for ; Thu, 21 Apr 2022 20:53:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9779E3858D37 Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-517-HC0KoazyNf-IXbOI4OIDRw-1; Thu, 21 Apr 2022 16:53:56 -0400 X-MC-Unique: HC0KoazyNf-IXbOI4OIDRw-1 Received: by mail-qk1-f198.google.com with SMTP id j12-20020ae9c20c000000b0069e8ac6b244so4159901qkg.1 for ; Thu, 21 Apr 2022 13:53:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=92dertYlgPd8rktiQg6dRCR9P/Ax2fKLZJ+1352nbM0=; b=tDDMXgAeKpFStE3A5JPJNOxPcwbmsLTHGlApWBfbBKB/2rqocy55YJjiovxKxGJtyo 9Df+u2HuJ+LNUqzGthAjn//dQPQ0C1CID/ZEeicicglsRkgQ+jtriG1x5FJQZNppUVWg fKiS8FslqTdVJ8XRR1sovAZR84APITNpTvh5PfWcr0Vr9hdrEDPP+gr7epdFLBKFmOu5 0SM9TXhbxGYJ8xfGUTaSg6hUD88p3ePDWbjV7KBE/Ss5cYPRhLIBLsJWMMMdaW0aVPTG DF9DnVYl0c5DkbRhH2XiXKu3K0uTbSX/ebZ8LiOEXPDGQZXMcLz/V0tELcg/qqHKIQEO S5cg== X-Gm-Message-State: AOAM532hIIRNDb7iyS9j48P3kkq85F7GJYNAg4wAiQqaajpqISZ2AfSy PzK3UJXu8vkP8JOFOOAGLUzsPWv8hCgiaJXudwGh1nHxdnaoiogzvbhp8v8DroG4lCZsHGmkWY4 DdQMWRBwU8k+cL1VWA7nMK5a5yT3ZrqySO67jvdW8 X-Received: by 2002:a05:6214:5284:b0:443:dd21:7db3 with SMTP id kj4-20020a056214528400b00443dd217db3mr1300816qvb.27.1650574435595; Thu, 21 Apr 2022 13:53:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwo/ar7qotdnkPt1Nep296jnjXSzULR7C9/N3O7IOwU661hBcr9PCnqqhz1NM8b3KPlK0ou43LmTEWx5f5GDYQ= X-Received: by 2002:a05:6214:5284:b0:443:dd21:7db3 with SMTP id kj4-20020a056214528400b00443dd217db3mr1300810qvb.27.1650574435452; Thu, 21 Apr 2022 13:53:55 -0700 (PDT) MIME-Version: 1.0 References: <20220112030755.434016-1-amerey@redhat.com> <9e72049a6e8b9a964d68cfc70b98aea682911b13.camel@klomp.org> In-Reply-To: <9e72049a6e8b9a964d68cfc70b98aea682911b13.camel@klomp.org> From: Aaron Merey Date: Thu, 21 Apr 2022 16:53:44 -0400 Message-ID: Subject: Re: [PATCH] [PATCH] debuginfod: Use the debuginfod-size response header To: Mark Wielaard Cc: elfutils-devel@sourceware.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, 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: Thu, 21 Apr 2022 20:53:59 -0000 On Thu, Mar 31, 2022 at 1:44 PM Mark Wielaard wrote: > Just a question about this part: > > > + /* If Content-Length is -1, try to get the size from > > + X-Debuginfod-Size */ > > + if (dl_size == -1 && c->winning_headers != NULL) > > + { > > + double xdl; > > + char *hdr = strstr(c->winning_headers, "x-debuginfod-size"); > > + > > + if (hdr != NULL > > + && sscanf(hdr, "x-debuginfod-size: %lf", &xdl) == 1) > > + dl_size = (xdl >= (double)(LONG_MAX+1UL) ? LONG_MAX : (long)xdl); > > + } > > + } > > In debuginfod.cxx the header is spelled all uppercase as "X-DEBUGINFOD- > SIZE" which is also what is checked for in the run-debuginfod-response- > headers.sh test. So shouldn't the above also be all uppercase or should > you use strcasestr? strcasestr is definitely better here. I meant to replace strstr with it but it looks like I missed that. > When using sscanf why are you using a double and %lf? Isn't it simpler > to use a long and %ld? It was done out of an (excessive) abundance of caution in case the value from the header was greater than LONG_MAX. x-debuginfod-size is derived from an off_t value so this currently isn't possible, so yes it would be simpler to stick with long and %ld. Fixed. > Is there a way to test this easily? When would Content-Length not be > available? AFAIK Content-Length isn't available only when a debuginfod server is configured with an httpd proxy that compresses files on-the-fly. If the response headers are finalized before compression is finished, Content-Length won't be present. Short of setting up an httpd-proxied server in the testsuite I'm not sure exactly how to test this. We currently have tests that check for the presence of x-debuginfod-size and we could add tests to at least verify that the value in the header matches the uncompressed size of the file being transferred. Aaron