From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pve-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 9ECEC1FF15E for <inbox@lore.proxmox.com>; Tue, 8 Apr 2025 09:28:01 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A1178C807; Tue, 8 Apr 2025 09:27:57 +0200 (CEST) Message-ID: <90bc6a8a-473c-4f3b-af49-603d2cdeacd2@proxmox.com> Date: Tue, 8 Apr 2025 09:27:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20250305214447.128975-1-admin@truthsolo.net> <mailman.798.1741211145.293.pve-devel@lists.proxmox.com> Content-Language: en-US From: Fiona Ebner <f.ebner@proxmox.com> In-Reply-To: <mailman.798.1741211145.293.pve-devel@lists.proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.037 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH pve-http-server v2 1/1] fix unexpected EOF for client when closing TLS session X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com> Am 05.03.25 um 22:45 schrieb Rob Rozestraten via pve-devel: > When pve-http-server initiates the closure of a TLS session, it does not > send a TLS close notify, resulting in an unexpected EOF error on systems > with recent crypto policies. This can break functionality with other > applications, such as Foreman[0]. > > This behavior can be observed in the following cases: > > * client uses HTTP/1.0 (no keepalive; server closes connection) > * client sends no data for 5 sec (timeout; server closes connection) > * server responds with 400 (no keepalive; server closes connection) > > This patch sends the TLS close notify prior to socket teardown, > resulting in clean closure of TLS connections and no client error. > > It also moves shutdown() to after the clearing of handlers. The reason > for this is stoptls() must come before shutdown(), but it also triggers > on_drain(), which calls client_do_disconnect() again. The extra call to > client_do_disconnect() is avoided inside accept_connections() by commit > f737984, but perhaps clearing the handlers prior to shutdown() will > avoid it in all cases. > > [0]: https://github.com/theforeman/foreman_fog_proxmox/issues/325 > I feel like the questions regarding blocking/missing client ack from Fabian from v1 are not answered yet: > If I read the docs right, this could block (would that be an issue here?) and could potentially destroy the handle (so that might need to be rechecked afterwards to prevent spurious warnings?) > > what happens if we initiate the teardown, and the client never acks it? _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel