From: Vsevolod Stakhov <vsevolod@rspamd.com>
Date: Sat, 6 Jun 2026 17:00:24 +0000 (+0100)
Subject: [Minor] checkv3: trim verbose comments to house style
X-Git-Tag: 4.1.1~30^2
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=5549082c2234a54c61691e0f0097287c5ecc28f2;p=thirdparty%2Frspamd.git

[Minor] checkv3: trim verbose comments to house style

Condense the multi-line explanatory blocks added with the negotiation
reply to single-line notes, and drop a dangling 'see contract above'
reference that pointed to nothing in the source.
---

diff --git a/src/client/rspamdclient.c b/src/client/rspamdclient.c
index ec3bb85262..4dc5a4f6e1 100644
--- a/src/client/rspamdclient.c
+++ b/src/client/rspamdclient.c
@@ -968,11 +968,9 @@ rspamd_client_command_v3(struct rspamd_client_connection *conn,
 					"multipart/form-data; boundary=%s", boundary);
 
 	/*
-	 * Request the multipart protocol explicitly. The result-part serialization
-	 * (json vs msgpack) is mirrored from the metadata Content-Type we send
-	 * above, so the Accept media type only needs to select the envelope, not
-	 * the serialization. Asking for application/json|msgpack here would instead
-	 * select a single-body v2 reply, which this client does not expect.
+	 * Request the multipart protocol. The result serialization mirrors the
+	 * metadata Content-Type, so Accept only selects the envelope; asking for
+	 * application/json|msgpack would yield a single-body v2 reply we cannot parse.
 	 */
 	rspamd_http_message_add_header(req->msg, "Accept", "multipart/form-data");
 	if (compressed) {
diff --git a/src/libserver/multipart_response.hxx b/src/libserver/multipart_response.hxx
index 100581ea7f..616035aaa4 100644
--- a/src/libserver/multipart_response.hxx
+++ b/src/libserver/multipart_response.hxx
@@ -32,10 +32,9 @@ struct response_part {
 };
 
 /*
- * Top-level envelope type. Both variants use the same part layout
- * (Content-Disposition: form-data; name=...); only the multipart subtype in
- * the response Content-Type differs, which is what lets a client pick between
- * an HTTP form parser (form_data) and a MIME parser (mixed).
+ * Top-level envelope. Both keep the same form-data part layout; only the
+ * multipart subtype differs, letting a client pick an HTTP form parser
+ * (form_data) or a MIME parser (mixed).
  */
 enum class multipart_envelope {
 	form_data, /* multipart/form-data */
diff --git a/src/libserver/protocol.c b/src/libserver/protocol.c
index e5d18b125d..8064de1e88 100644
--- a/src/libserver/protocol.c
+++ b/src/libserver/protocol.c
@@ -3139,28 +3139,18 @@ rspamd_protocol_v3_not_acceptable(struct rspamd_http_message *msg,
 }
 
 /*
- * Build a v3 HTTP reply, negotiating the representation from Accept and the
- * compression from Accept-Encoding (see the negotiation contract above).
- * Returns the Content-Type string (allocated on the task pool, except for the
- * static literals) for use as the mime_type argument in
- * rspamd_http_connection_write_message.
+ * Build a v3 HTTP reply, negotiating the format from Accept and the
+ * compression from Accept-Encoding. Returns the Content-Type for
+ * rspamd_http_connection_write_message (task-pool string or static literal).
  */
 const char *
 rspamd_protocol_http_reply_v3(struct rspamd_http_message *msg,
 							  struct rspamd_task *task)
 {
-	/*
-	 * Proactive content negotiation. The representation is chosen solely from
-	 * the Accept header (never inferred from the request body), and compression
-	 * solely from Accept-Encoding. Advertise both so caches behave.
-	 */
+	/* Format depends on Accept, compression on Accept-Encoding */
 	rspamd_http_message_add_header(msg, "Vary", "Accept, Accept-Encoding");
 
-	/*
-	 * Supported representations in preference order. MULTIPART_FORM is first so
-	 * that an absent Accept or a wildcard media range (catch-all, or the
-	 * multipart wildcard) resolves to the multipart/form-data default.
-	 */
+	/* Preference order; FORM is first so absent/wildcard Accept defaults to it */
 	static const enum rspamd_http_content_type desired[] = {
 		RSPAMD_HTTP_CTYPE_MULTIPART_FORM,
 		RSPAMD_HTTP_CTYPE_MESSAGE_RFC822,
@@ -3184,11 +3174,7 @@ rspamd_protocol_http_reply_v3(struct rspamd_http_message *msg,
 		rep = matched;
 	}
 
-	/*
-	 * Single-body (v2-style) representations: delegate to the regular reply
-	 * writer, which serializes the result, updates history/stats and the log
-	 * pipe internally. There is no place for a rewritten-message part here.
-	 */
+	/* Single-body v2 reply: regular writer does serialization/history/stats */
 	if (rep == RSPAMD_HTTP_CTYPE_JSON || rep == RSPAMD_HTTP_CTYPE_MSGPACK) {
 		int out_type = (rep == RSPAMD_HTTP_CTYPE_MSGPACK) ? UCL_EMIT_MSGPACK
 														  : UCL_EMIT_JSON_COMPACT;