feat(http): add SizeLimitHandler to enforce request body size limit

[bladehan1]

What does this PR do?

Add Jetty SizeLimitHandler at the server handler level to enforce request body size limits for all HTTP and JSON-RPC endpoints, preventing OOM denial-of-service from oversized payloads.

Changes

• Introduce node.http.maxMessageSize and node.jsonrpc.maxMessageSize as independent, configurable size limits
• Default: 4 MB, consistent with gRPC defaults
• Support human-readable size values (e.g. 4m, 128MB) via HOCON getMemorySize() for all three size configs
• Wire SizeLimitHandler into HttpService.initContextHandler() as the outermost handler
• Each HttpService subclass (4 HTTP + 3 JSON-RPC) sets maxRequestSize from the corresponding config getter
• Initialize maxRequestSize with a safe 4MB default to prevent silent reject-all if a future subclass omits the assignment
• Deprecate Util.checkBodySize() — updated to use httpMaxMessageSize, retained as fallback for backward compatibility
• Existing node.rpc.maxMessageSize now also supports human-readable sizes (backward compatible — bare integers still treated as bytes)

Why are these changes required?

Previously, HTTP request body size was only validated at the application layer (Util.checkBodySize()), which reads the entire body into memory before checking. The JSON-RPC interface had no size validation at all. This allows an attacker to send arbitrarily large payloads, causing OOM and denial of service.

Moving the limit to the Jetty handler chain provides:

1. OOM protection — oversized payloads are never fully buffered into memory
2. Streaming enforcement — limits are enforced during read, not after full buffering
3. Unified coverage — all HTTP and JSON-RPC endpoints are protected by a single mechanism
4. Independent tuning — operators can configure HTTP and JSON-RPC limits separately

Scope and known limitations

This PR's primary goal is OOM protection, not uniform HTTP 413 responses.

Chunked transfer behavior differs by servlet type due to a pre-existing exception handling design in the servlet chain:

Request type	HTTP Servlets (132)	JSON-RPC Servlet
Content-Length exceeds limit	413 (Jetty rejects before dispatch)	413 (same)
Chunked / no Content-Length, exceeds limit	200 + error JSON {"Error":"BadMessageException"}	200 + empty body

Root cause: SizeLimitHandler truncates body read at the limit and throws BadMessageException (RuntimeException) during streaming.

• HTTP servlets have their own catch(Exception) → Util.processError() writes error JSON to the response body, so the client sees 200 + {"Error":"..."}.
• JsonRpcServlet delegates to jsonrpc4j, which internally catches exceptions during request parsing and returns an empty response → client sees 200 + empty body.

This is a pre-existing behavior of the jsonrpc4j library, not introduced by this PR. Any exception during request body parsing produces the same 200 empty body result, with or without SizeLimitHandler. OOM protection is effective in all cases — the body read is truncated regardless of the response status code. Returning 200 + empty body for malformed/oversized chunked requests is acceptable: it does not affect normal requests, increases attacker difficulty, and the alternative — pre-reading the request body to trigger the size limit (catch the exception to report the error), then wrapping the already-read body into an HttpServletRequestWrapper to continue the normal request flow — adds significant complexity for marginal benefit.

Closes #6604

Migration

This PR makes node.http.maxMessageSize and node.jsonrpc.maxMessageSize independent of node.rpc.maxMessageSize. Previously, HTTP servlets enforced their body limit through Util.checkBodySize(), which read the gRPC limit (node.rpc.maxMessageSize); JSON-RPC had no body-size validation at all.

Behavior change:

Limit	Before	After
HTTP body	bounded by node.rpc.maxMessageSize (via Util.checkBodySize)	node.http.maxMessageSize, default 4 MB
JSON-RPC body	not validated	node.jsonrpc.maxMessageSize, default 4 MB
gRPC message	node.rpc.maxMessageSize, default 4 MB	unchanged

Affected deployments: those that previously set node.rpc.maxMessageSize above 4 MB (for example 8m) and relied on the same limit applying to HTTP bodies. After upgrading, HTTP and JSON-RPC fall back to the new 4 MB default unless the matching key is set explicitly. The HTTP fallback was intentionally not preserved through node.rpc.maxMessageSize so that the new "independent per-protocol limit" contract stays clean.

Required action for affected operators:

node {
  rpc.maxMessageSize     = 8m   # gRPC, unchanged
  http.maxMessageSize    = 8m   # NEW: set explicitly to preserve prior HTTP body limit
  jsonrpc.maxMessageSize = 8m   # NEW: opt in to enable JSON-RPC body validation at the desired size
}

Deployments that did not customize node.rpc.maxMessageSize are unaffected (all three default to 4 MB).

This PR has been tested by

• SizeLimitHandlerTest (10 tests): boundary, independent limits, UTF-8 byte counting, chunked transfer, zero-limit, checkBodySize consistency
• JsonrpcServiceTest.testJsonRpcSizeLimitIntegration: real JSON-RPC integration test covering normal passthrough, Content-Length oversized (413), and chunked oversized (200 empty body)
• ArgsTest (5 new tests): human-readable sizes (KB/MB/GB × binary/SI), raw integer backward compatibility, zero-value, error paths (exceeds int max, negative, invalid unit, non-numeric)
• UtilTest: checkBodySize uses httpMaxMessageSize

Follow-up

• Fix chunked oversized JSON-RPC to return proper error — Won't fix: exception is swallowed inside jsonrpc4j, not in our servlet code. Fixing requires pre-reading the request body to trigger the size limit (catch the exception to report the error), then wrapping the already-read body into an HttpServletRequestWrapper to continue the normal request flow — significant test complexity for marginal benefit. Current behavior (200 + empty body) is acceptable.
• Remove Util.checkBodySize() callers once SizeLimitHandler is stable

Changed files

Component	Changes
HttpService	Add maxRequestSize field (default 4MB), wire SizeLimitHandler in initContextHandler()
Args / ConfigKey / CommonParameter	Parse node.http.maxMessageSize and node.jsonrpc.maxMessageSize; refactor all three to use getMemorySize(); extract parseMaxMessageSize private helper to dedupe range-check / cast logic; comment legacy maxMessageSize field as the gRPC counterpart
7 service subclasses	Set maxRequestSize from protocol-specific config getter
Util.checkBodySize()	Mark @Deprecated, switch to httpMaxMessageSize
config.conf	Add documented config examples for HTTP, RPC, JSON-RPC size limits with zero-value behavior
SizeLimitHandlerTest	New: 10 tests covering HTTP limits, boundary, UTF-8, chunked, independence, zero-limit, checkBodySize consistency
JsonrpcServiceTest	New: testJsonRpcSizeLimitIntegration — real JSON-RPC integration test
ArgsTest	New: 5 tests for human-readable parsing (KB/MB/GB), error paths
UtilTest	New: checkBodySize consistency test

[xxo1shine]

@bladehan1 One observation on the config validation in Args.java: the guard currently rejects <= 0 values with TronError, but there is no upper-bound check. An operator who accidentally sets node.http.maxMessageSize = 2147483647 would silently run with a 2 GB limit. Adding a reasonable maximum (e.g. 128 MB) with an explicit warn-or-throw would make misconfiguration more visible.

[bladehan1]

@xxo1shine
Thanks for the review. I think that when users manually configure values, it's unnecessary to set all boundaries except for error-prone values. Especially for values ​​that are obviously likely to have problems, setting boundaries is unnecessary.

[waynercheung]

[SHOULD] With the updated PR scope, I no longer see the chunked 413 gap itself as a contract mismatch, since the description now explicitly scopes this PR to OOM protection rather than uniform HTTP status behavior. The remaining gap is test realism: SizeLimitHandlerTest still does not exercise the production JSON-RPC stack, because the /jsonrpc path is backed by a synthetic BroadCatchServlet, not the real JsonRpcServlet -> jsonrpc4j chain. Since the PR still claims protection for JSON-RPC endpoints, I strongly recommend either adding one real JSON-RPC integration case or making the test naming/comments explicit that this is validating generic HttpInput interception rather than end-to-end JSON-RPC behavior.

[waynercheung]

[NIT] SizeLimitHandlerTest relies heavily on banner-style ruler comments such as // -- ... -------- throughout the file. This style adds visual noise without structural value, and is harder to maintain - new tests may not fit neatly into an existing section, and the dashes need manual alignment. The usual best practice here is to rely on descriptive test names, minimal section comments, and helper methods / smaller test classes for grouping, rather than heavy visual separators.

Note also that one comment has already drifted from the implementation: the Javadoc on testChunkedBodyWithinLimit still reads "succeed (EchoServlet)", but the servlet under test is now BroadCatchServlet. Please update that reference while cleaning up the comments.

[waynercheung]

[DISCUSS] One compatibility point is worth calling out explicitly in the PR description / release notes: before this change, many existing HTTP servlet paths were effectively bounded by node.rpc.maxMessageSize via Util.checkBodySize(). After introducing independent node.http.maxMessageSize, deployments that previously increased only node.rpc.maxMessageSize (for example to 8m) will fall back to the new 4 MB HTTP default unless they set node.http.maxMessageSize explicitly.

I'm not suggesting we restore rpcMaxMessageSize as the HTTP fallback, because that would blur the new "independent per-protocol config" contract again. But the migration impact should be documented clearly so operators do not get a silent behavior change on upgrade.

Suggest adding a short Migration subsection to the PR description, for example:

If your deployment previously customized node.rpc.maxMessageSize (for example = 8m), HTTP endpoints were implicitly bounded by that value through Util.checkBodySize(). After this change, set node.http.maxMessageSize (and node.jsonrpc.maxMessageSize if applicable) explicitly if you want to preserve the previous effective limit.

Default deployments (all three at 4 MB) are unaffected.

Note: JSON-RPC endpoints previously had no unified pre-ingress size limit, so node.jsonrpc.maxMessageSize = 4m is a new enforcement point. Operators should review client request peak sizes before upgrade.

[bladehan1]

[DISCUSS] One compatibility point is worth calling out explicitly in the PR description / release notes: before this change, many existing HTTP servlet paths were effectively bounded by node.rpc.maxMessageSize via Util.checkBodySize(). After introducing independent node.http.maxMessageSize, deployments that previously increased only node.rpc.maxMessageSize (for example to 8m) will fall back to the new 4 MB HTTP default unless they set node.http.maxMessageSize explicitly.

Agreed, this is a real silent behavior change on upgrade and should not stay implicit. I've added a ## Migration subsection to the PR description covering:

• Before/after table for HTTP, JSON-RPC, gRPC body limits
• Which deployments are affected (those that bumped node.rpc.maxMessageSize above 4 MB and relied on it covering HTTP)
• A concrete node { ... } snippet showing the explicit keys to set to preserve prior behavior
• An explicit note that the HTTP fallback through node.rpc.maxMessageSize was intentionally not preserved, in order to keep the new "independent per-protocol limit" contract clean — matching your point that restoring the fallback would blur it

I deliberately did not add a migration note to config.conf itself: config files document current behavior, not transition history, and accumulating historical notes there ages poorly. Migration docs belong in PR description / release notes, which is where this lives now.

[bladehan1]

Both addressed — pushed as a single follow-up commit.

1. Legacy naming comment on maxMessageSize

Added a brief two-line comment on CommonParameter.maxMessageSize clarifying that the legacy field refers to the gRPC limit, alongside the explicit httpMaxMessageSize / jsonRpcMaxMessageSize siblings. Kept it as a plain // comment (not Javadoc) to match the rest of the field block, which is uncommented. A rename to rpcMaxMessageSize would be the cleaner long-term fix, but it's a public field with cross-module callers, so out of scope here.

2. Extracted parseMaxMessageSize helper

Net effect: ~16 lines removed across the three blocks, error messages now guaranteed consistent (the previous string-concat blocks had subtly diverged on line breaking), and adding a future protocol limit becomes a one-liner.

One adjustment to your suggested signature: the helper returns long rather than int, because httpMaxMessageSize and jsonRpcMaxMessageSize are typed long (matching Jetty's SizeLimitHandler(long, long) expectation). The rpc assignment retains an explicit (int) cast at the call site to keep the gRPC int32 hard constraint visible — same idea as the cap rationale we discussed earlier.

Resulting call sites:

long defaultMaxMessageSize = GrpcUtil.DEFAULT_MAX_MESSAGE_SIZE;
PARAMETER.maxMessageSize = (int) parseMaxMessageSize(
    config, ConfigKey.NODE_RPC_MAX_MESSAGE_SIZE, defaultMaxMessageSize);
PARAMETER.httpMaxMessageSize = parseMaxMessageSize(
    config, ConfigKey.NODE_HTTP_MAX_MESSAGE_SIZE, defaultMaxMessageSize);
PARAMETER.jsonRpcMaxMessageSize = parseMaxMessageSize(
    config, ConfigKey.NODE_JSONRPC_MAX_MESSAGE_SIZE, defaultMaxMessageSize);

ArgsTest (including the error-path cases for each of the three keys) passes unchanged.

[bladehan1]

Resolved conflict with the develop branch.
Configuration parameter settings.

[waynercheung]

LGTM