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 455971FF189
for <inbox@lore.proxmox.com>; Fri, 21 Mar 2025 10:58:03 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 645E71ABAE;
Fri, 21 Mar 2025 10:58:02 +0100 (CET)
From: Lukas Wagner <l.wagner@proxmox.com>
To: pve-devel@lists.proxmox.com
Date: Fri, 21 Mar 2025 10:56:59 +0100
Message-Id: <20250321095700.106077-1-l.wagner@proxmox.com>
X-Mailer: git-send-email 2.39.5
MIME-Version: 1.0
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.009 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
URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
information. [ietf.org, gotify.rs, webhook.rs, proxmox.com]
Subject: [pve-devel] [PATCH proxmox 1/2] notify: webhook: gotify: set
Content-Length header
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>
To quote from RFC 9110 [1]:
A user agent SHOULD send Content-Length in a request when
the method defines a meaning for enclosed content and it
is not sending Transfer-Encoding. For example, a user agent
normally sends Content-Length in a POST request even when
the value is 0 (indicating empty content).
A user agent SHOULD NOT send a Content-Length header field
when the request message does not contain content and the
method semantics do not anticipate such data.
It seemed like our HTTP client lib did not set the header
automatically, which is why we should do it manually.
While most services seemed to have worked fine without setting
the header, some Microsoft services seem to require it
to accept the webhook request [2].
[1] https://datatracker.ietf.org/doc/html/rfc9110#name-content-length
[2] https://forum.proxmox.com/threads/158827
Signed-off-by: Lukas Wagner <l.wagner@proxmox.com>
---
proxmox-notify/src/endpoints/gotify.rs | 4 ++++
proxmox-notify/src/endpoints/webhook.rs | 19 ++++++++++++++++++-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/proxmox-notify/src/endpoints/gotify.rs b/proxmox-notify/src/endpoints/gotify.rs
index 3e977131..e154daab 100644
--- a/proxmox-notify/src/endpoints/gotify.rs
+++ b/proxmox-notify/src/endpoints/gotify.rs
@@ -136,6 +136,10 @@ impl Endpoint for GotifyEndpoint {
format!("Bearer {}", self.private_config.token),
),
("X-Gotify-Key".into(), self.private_config.token.clone()),
+ (
+ http::header::CONTENT_LENGTH.to_string(),
+ body.len().to_string(),
+ ),
]);
let proxy_config = context()
diff --git a/proxmox-notify/src/endpoints/webhook.rs b/proxmox-notify/src/endpoints/webhook.rs
index 34dbac54..604777c7 100644
--- a/proxmox-notify/src/endpoints/webhook.rs
+++ b/proxmox-notify/src/endpoints/webhook.rs
@@ -35,7 +35,7 @@ pub(crate) const WEBHOOK_TYPENAME: &str = "webhook";
const HTTP_TIMEOUT: Duration = Duration::from_secs(10);
#[api]
-#[derive(Serialize, Deserialize, Clone, Copy, Default)]
+#[derive(Serialize, Deserialize, Clone, Copy, Default, PartialEq)]
#[serde(rename_all = "kebab-case")]
/// HTTP Method to use.
pub enum HttpMethod {
@@ -347,6 +347,23 @@ impl WebhookEndpoint {
builder = builder.header(header.name.clone(), value);
}
+ // From https://datatracker.ietf.org/doc/html/rfc9110#name-content-length :
+ //
+ // A user agent SHOULD send Content-Length in a request when the method
+ // defines a meaning for enclosed content and it is not sending
+ // Transfer-Encoding. For example, a user agent normally sends
+ // Content-Length in a POST request even when the value is 0 (indicating
+ // empty content). A user agent SHOULD NOT send a Content-Length header
+ // field when the request message does not contain content and the
+ // method semantics do not anticipate such data.
+ //
+ // -> send the header always, unless we do a get with no body (which is the expected case
+ // for GET)
+ let content_length = body.as_bytes().len();
+ if !(self.config.method == HttpMethod::Get && content_length == 0) {
+ builder = builder.header(http::header::CONTENT_LENGTH, content_length);
+ }
+
let request = builder
.body(body)
.map_err(|err| self.mask_secret_in_error(err))
--
2.39.5
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel