in_http: minimal http response and Improved Content-Type detection

[kalavt]

Summary

This PR modifies the HTTP server root endpoint (/) to return minimal information instead of exposing sensitive system details.

Changes

Before:

{
  "fluent-bit": {
    "version": "5.0.0",
    "edition": "Community",
    "flags": ["FLB_HAVE_SYS_WAIT_H", "FLB_HAVE_SIMD", ...]
  }
}

After:

{
  "status": "ok"
}

Motivation

The HTTP server's root endpoint previously exposed sensitive information including:

• Exact version number
• Edition type (Community/Enterprise)
• Detailed build flags and capabilities

This information disclosure could be leveraged by attackers to:

• Identify specific vulnerabilities in the version
• Understand system capabilities and attack surface
• Fingerprint the deployment environment

This change reduces the attack surface by providing only a minimal health status response.

Modified Files

• src/http_server/flb_hs_endpoints.c: Simplified endpoint_root() function to return minimal status

Testing

• Example configuration file for the change

  [SERVICE]
      HTTP_Server  On
      HTTP_Listen  0.0.0.0
      HTTP_Port    2020
  

• Debug log output from testing the change

  # Test the endpoint
  curl http://localhost:2020/
  # Expected output: {"status":"ok"}

• Attached Valgrind output that shows no leaks or memory corruption was found

Packaging

• Run local packaging test showing all targets build
• Set ok-package-test label to test for all targets

Documentation

• Documentation required for this feature

  • Document that the root endpoint now returns minimal information
  • Update any documentation referencing the version/edition/flags output

Backporting

• Backport to latest stable release (recommended for security improvement)

Notes

• Other monitoring endpoints (/api/v1/metrics, /api/v1/health, etc.) remain unchanged
• Users needing version information can still access it through other means (logs, CLI)
• This is a security hardening measure to reduce information disclosure

---

Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.

Summary by CodeRabbit

• Bug Fixes
  • Root API endpoint now returns a minimal status indicator ("ok") instead of detailed version/configuration data.
  • Improved Content-Type detection for incoming HTTP requests: JSON and form-encoded payloads are recognized using prefix-and-boundary checks, and requests with invalid Content-Type now receive a 400 error.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Endpoint root response reduced to a minimal JSON payload {"status":"ok"}. Content-Type detection for incoming requests updated to case-insensitive prefix checks for application/json and application/x-www-form-urlencoded with explicit delimiter validation, applied to both HTTP/1.x and HTTP/2 paths.

Changes

Cohort / File(s)	Summary
Endpoint response simplification src/http_server/flb_hs_endpoints.c	Replaced detailed Fluent Bit metadata map (version, edition, build flags) with a minimal JSON payload containing only "status": "ok"; removed nested metadata construction logic.
Content-Type prefix checks plugins/in_http/http_prot.c	Replaced exact/token Content-Type checks with case-insensitive prefix checks (application/json, application/x-www-form-urlencoded) and added delimiter/boundary validation after the prefix in both HTTP/1.x and HTTP/2 (ng) code paths; returns 400 on invalid Content-Type.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 I nibbled through the verbose map today,
A tiny "status: ok" is now my play.
I sniffed the headers, checked each little seam,
Trimmed the fluff, now responses are lean.
🥕✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately captures both main changes: the minimal HTTP response and improved Content-Type detection in the in_http plugin.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

plugins/in_http/http_prot.c (1)

771-774: Inconsistent handling: URL-encoded still requires exact length.

The JSON check was updated to use >= 16 (prefix match), but the URL-encoded check still requires exact length == 33. This means application/x-www-form-urlencoded; charset=utf-8 will be rejected on HTTP/1.x but accepted on HTTP/2 (line 1228 uses prefix match).

For consistency with the JSON fix and HTTP/2 behavior, consider changing to a prefix match:

Suggested fix

-    if (header->val.len == 33 &&
+    if (header->val.len >= 33 &&
         strncasecmp(header->val.data, "application/x-www-form-urlencoded", 33) == 0) {

🧹 Nitpick comments (1)

plugins/in_http/http_prot.c (1)

1224-1230: HTTP/2 content-type checks are consistent with each other but differ slightly from HTTP/1.x.

Both JSON and URL-encoded use prefix matching here (no length guard), which is more permissive than HTTP/1.x. While strncasecmp is safe with shorter strings (stops at null terminator), consider adding a length guard for consistency with line 767, or removing the length guard from line 767 to match this style.

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

plugins/in_http/http_prot.c (1)

1219-1230: Mirror the delimiter guard for HTTP/2 Content-Type parsing.

Same prefix-only behavior here; add a delimiter check so parameters are allowed but invalid tokens are rejected.

🔧 Proposed fix

     struct flb_http *ctx;
+    size_t ct_len;
@@
-    if (strncasecmp(request->content_type, "application/json", 16) == 0) {
+    ct_len = strlen(request->content_type);
+
+    if (ct_len >= 16 &&
+        strncasecmp(request->content_type, "application/json", 16) == 0 &&
+        (ct_len == 16 ||
+         (ct_len > 16 &&
+          (request->content_type[16] == ';' ||
+           isspace((unsigned char) request->content_type[16]))))) {
         type = HTTP_CONTENT_JSON;
     }
 
-    if (strncasecmp(request->content_type, "application/x-www-form-urlencoded", 33) == 0) {
+    if (ct_len >= 33 &&
+        strncasecmp(request->content_type, "application/x-www-form-urlencoded", 33) == 0 &&
+        (ct_len == 33 ||
+         (ct_len > 33 &&
+          (request->content_type[33] == ';' ||
+           isspace((unsigned char) request->content_type[33]))))) {
         type = HTTP_CONTENT_URLENCODED;
     }

🤖 Fix all issues with AI agents

In `@plugins/in_http/http_prot.c`:
- Around line 767-774: The prefix checks accept tokens like "application/jsonp";
tighten them by validating the character after the matched prefix: after
confirming strncasecmp(header->val.data, "application/json", 16) == 0, also
require that header->val.len == 16 or that the next byte header->val.data[16] is
';' or whitespace (use isspace from ctype.h); similarly, after strncasecmp(...
"application/x-www-form-urlencoded", 33) == 0 require header->val.len == 33 or
header->val.data[33] is ';' or whitespace before setting type =
HTTP_CONTENT_JSON or HTTP_CONTENT_URLENCODED respectively.

[kalavt]

@edsiper & @cosmo0920 let me know your comments, THX,.