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 1kzFUL-00006J-N2 for pgadmin-hackers@arkaria.postgresql.org; Tue, 12 Jan 2021 08:57:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kzFUK-00073M-Ml for pgadmin-hackers@arkaria.postgresql.org; Tue, 12 Jan 2021 08:57:16 +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 1kzFUJ-00073E-UQ for pgadmin-hackers@lists.postgresql.org; Tue, 12 Jan 2021 08:57:16 +0000 Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kzFUF-0001Zp-Qc for pgadmin-hackers@lists.postgresql.org; Tue, 12 Jan 2021 08:57:15 +0000 Received: by mail-ed1-x52e.google.com with SMTP id w10so495735edu.5 for ; Tue, 12 Jan 2021 00:57:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aX8E7SjUa/fTYbgJ4GEVlNR1Bjf7E9UMTaCFV8L15MQ=; b=FmyV8l3VnFTMctVVReZH3UxgN9CwJvBrM39tYrhQtCjX3A3EOCdu7XbctOCw0kH4iW fgpd42MkkXx3fO1ciA5KJ67toaMWAvpMgFqmm/TB2ZQ/L4jh/xnH+XIehgH7mpD7rTVd Ixzfwuj79byKxturOCYzcCLZLVdNs+oHgtm5qJkwShbylKqfVf4hnSx9REqMPCfKJDce y6tXfk0TfCyVO21ORsYqZoz/Bj6bcPF8AOxANu5nx1cKuJRO8MY7Uwes6JfSoCAo2cR6 cKyLDeuFgXXUbYqLvFPiJ2KnAvPssbPRTvKxl2e7e6N30ZwsyusS12o9KdyYdvVuNNz3 NJaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aX8E7SjUa/fTYbgJ4GEVlNR1Bjf7E9UMTaCFV8L15MQ=; b=rgmIU9KPwlk60caBr161k8lR3GRfCx5sp2l5yCc8dI4aRIvOicIOzlJrIsjMmcq+QZ 5NC2uhlmzMj5dJ4b32Xul3cZEPXcDbTucHB078NN4STwOKyMp9rqEKz8iyBv3lihmaSE Tx1US9ybvYBvbHkwfINEWebpyEFbFlInWnTeE2DsvuiwPW9eRTzs3EbNT6qqgGD99jJF rC9CdfN+P4Fotcx9cA1wtrc5bxHcKz00RbJzXcPHZWz39LNktibvKHVNU23NzaO5KmZF DzQ+1m2X/Xu+0/eOmJHc/w7FX5Dyrd/X6cxJUsjp5TSqDdi2Wb9tMVJmueIx/2An1Otd vpjQ== X-Gm-Message-State: AOAM532shXLBm2IEUg7IPNUvyW9qmvwk9NHbNpSCUKqByKGTEIXw8/ms SS8sxszGsCvc1qg6jwskdq/fum5LA9n82yDlZz8LBA== X-Google-Smtp-Source: ABdhPJyEXL27aIHQbrUiKdun8yOaxBjOcihi+29mLRN1TFMkG5WswssGtjisUydiWXP8mmaLtmqXRdVqSGcjb5dTtjk= X-Received: by 2002:a05:6402:1714:: with SMTP id y20mr2476888edu.360.1610441830326; Tue, 12 Jan 2021 00:57:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Tue, 12 Jan 2021 08:56:59 +0000 Message-ID: Subject: Re: Somewhat excessive version checks To: Magnus Hagander Cc: pgadmin-hackers Content-Type: multipart/alternative; boundary="0000000000003a79d105b8b03581" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000003a79d105b8b03581 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 11, 2021 at 10:06 PM Magnus Hagander wrote: > 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*. > Every time the server starts, which is a little different, but still... > > Wouldn't it make sense to rate limit that to checking say once per 24 > hours maximum? Or even 48? > That certainly wouldn't be a bad idea. > > 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. > Patches welcome! -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EDB: http://www.enterprisedb.com --0000000000003a79d105b8b03581 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 11, 2021 at 10:06 PM Magn= us Hagander <magnus@hagander.net<= /a>> wrote:
H= i!

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?

That certain= ly wouldn't be a bad idea.
=C2=A0

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.

Patches welcome!=C2=A0

--
--0000000000003a79d105b8b03581--