Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kz5KA-0004Na-Ep for pgadmin-hackers@arkaria.postgresql.org; Mon, 11 Jan 2021 22:06:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kz5K9-00089Y-83 for pgadmin-hackers@arkaria.postgresql.org; Mon, 11 Jan 2021 22:06:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kz5K9-00089R-2g for pgadmin-hackers@lists.postgresql.org; Mon, 11 Jan 2021 22:06:05 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kz5K1-0004im-6G for pgadmin-hackers@lists.postgresql.org; Mon, 11 Jan 2021 22:06:03 +0000 Received: by mail-lf1-x133.google.com with SMTP id o13so303819lfr.3 for ; Mon, 11 Jan 2021 14:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hagander-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=FLfLfRM6TGqtCmRFEy6J4TR0ZKeXrUxnd1QIGm7M1AQ=; b=B9NB9HXh8Y1zKJP2HgIODjTEQOpFusfQKLHQmOA3Mo7PMDkEXIJc4bYMFr/2Iw42bs 3P+weM14qdn7wONJ4/GXlvN+dU9AjQPCCbTM7s7YjQQy44JQexZqyIOKHzShYuRER4nq pKpZznjSWTtoO9y6pziKAwfRMFBi5KHZppLzQFk8//ZGYjnFPJlzdja6YYbQ13avbL+e 0MAMphpWj/evQEeuaB3qJUtDUhqM1DMm8boHp/IyKODpC8Xx0roBmR2Rq84aY0XEzsL3 /lAzKKpY9tl+BqN3ad6dLuTQFHZhd2N/z4NlAdZBMjahnKPXS9zI2AeNuubJSOgsh96x 4FAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FLfLfRM6TGqtCmRFEy6J4TR0ZKeXrUxnd1QIGm7M1AQ=; b=KnZTYTbgAmKGJgEOkZHwz7k4u8UHIJDd70T9it5HqiLcQ4PJLjBH9eXIyFeh5E9TjC fMdGhn9NcwmMgD8iNnpnFuqp8BUPz5AUJ3Hmcifu6OEaUaq7jyDudX+tlP6WXH6mcMxX GZECF4fqr3C4b8IjOW1gmSvEX0RjIso+7gy1LWptr2Mva0O1kN1tFr/hOsolWCYw/U5F ikUKkSUMSTJ6Kox1/6l6kHt6VLSfX6b9+UAAHsv3JIztGi4T8txJKFIP5vtZaQiWIlcC kaBSIt9AmsXpWvE2r9r7VFljx2CiPkUGzAfk/bsQZ7VlwM1bUI/cB3h11+A8Iuea5mo0 pRHw== X-Gm-Message-State: AOAM531z4Id7mkUA4uhJHP7PYf0p/NtixZS2kK3zExv9x+8Uu2UGpjll TqAclsqR+1TmWzlF8Kqr0yrABrCJpYifIwcuU6kApcF+KdI= X-Google-Smtp-Source: ABdhPJxbsjZjjyzPKml3icdKQwT7tJHYu9TfiqcMjaLGCNECpXNqK2uAZ10yNRZV7itpUZ7yW47wYzmSG5QTo+j3uNY= X-Received: by 2002:ac2:5a09:: with SMTP id q9mr639729lfn.209.1610402755869; Mon, 11 Jan 2021 14:05:55 -0800 (PST) MIME-Version: 1.0 From: Magnus Hagander Date: Mon, 11 Jan 2021 23:05:44 +0100 Message-ID: Subject: Somewhat excessive version checks To: pgadmin-hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi! If I read the code correctly, pgadmin will (unless turned off) hit the website to check the version.json file for updates *every time it starts*. Wouldn't it make sense to rate limit that to checking say once per 24 hours maximum? Or even 48? It seems nobody needs the update *that* quickly, and AFAICT it does call out to make that check synchronously on startup which means the user is waiting. And if/when doing that, it would be useful to include an If-Modified-Since header on the request, so the server can just respond with a tiny 304 reply when there is no update, which is going to be the majority of the time. Or possibly even more efficiently, create a custom etag and use If-None-Matches. If you make that etag be say the version that the client has, it becomes very cheap to check and you don't need to track any extra data. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/