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

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

16 files changed, +617 / -8

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()
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]

Re-checking the current PR head (6f0a0f0), I still do not see the changes described in the reply on this branch yet.

Specifically:

• SizeLimitHandlerTest still contains the banner-style section comments, and the stale EchoServlet reference is still present.
• I do not see the new testJsonRpcSizeLimitIntegration() in JsonrpcServiceTest.
• The synthetic /jsonrpc tests in SizeLimitHandlerTest are still present.
• Util.checkBodySize() is still using body.getBytes() with the platform default charset.

If there is a newer push on another branch or commit, please point me to it. Otherwise I think these threads should stay open until the code is actually updated in this PR.

[bladehan1]

@waynercheung

The push was a little late, but you can view it now.
As mentioned above, Util.checkBodySize() no longer adds body.getBytes.
Another issue has been updated.

[waynercheung]

[NIT] A few of the newly added test comments use decorative non-ASCII punctuation such as → and —. This is not a correctness issue, and Google Java Style does allow Unicode where it improves readability, but these particular symbols are decorative rather than semantic. For consistency with the rest of the Java codebase, I’d prefer plain ASCII punctuation (->, -) in comments. The UTF-8 test literals themselves (for example 一 / 测试地址) are of course justified and should stay.

[waynercheung]

[DISCUSS] node.rpc.maxMessageSize already has a stronger fail-fast guard because the gRPC API ultimately requires an int (<= Integer.MAX_VALUE). By contrast, node.http.maxMessageSize and node.jsonrpc.maxMessageSize are currently accepted as any non-negative long. I’m not convinced they should be forced to the same Integer.MAX_VALUE cap, but do we want some operator guardrail here as well (for example a startup warning or a documented recommended upper bound for suspiciously large values)? Very large HTTP / JSON-RPC limits materially weaken the intended OOM protection, and values above Integer.MAX_VALUE also exceed the effective range of the deprecated checkBodySize() fallback.

[bladehan1]

Done. Replaced all → and — with -> and - in newly added test comments across SizeLimitHandlerTest and JsonrpcServiceTest.

[bladehan1]

[DISCUSS] node.rpc.maxMessageSize already has a stronger fail-fast guard because the gRPC API ultimately requires an int (<= Integer.MAX_VALUE). By contrast, node.http.maxMessageSize and node.jsonrpc.maxMessageSize are currently accepted as any non-negative long. I’m not convinced they should be forced to the same Integer.MAX_VALUE cap, but do we want some operator guardrail here as well (for example a startup warning or a documented recommended upper bound for suspiciously large values)? Very large HTTP / JSON-RPC limits materially weaken the intended OOM protection, and val

Valid concern. For this PR the focus is OOM baseline protection — adding an upper-bound guardrail here would expand scope and potentially delay the core fix. A startup warning for suspiciously large values (e.g. > 128 MB) is worth a follow-up, but I'd prefer to land this first.

[waynercheung]

For this PR the focus is OOM baseline protection — adding an upper-bound guardrail here would expand scope and potentially delay the core fix.

[SHOULD] I agree this is not the same kind of hard API constraint as gRPC, but I still think the config layer should fail fast for HTTP / JSON-RPC values above Integer.MAX_VALUE in this PR.

Reason: although Jetty accepts long, the current java-tron request-processing path does not realistically support arbitrarily large bodies. Many downstream paths still materialize request bodies into String / byte[], and once httpMaxMessageSize > Integer.MAX_VALUE, the deprecated checkBodySize() fallback also becomes ineffective.

Since this PR is already touching the shared maxMessageSize parsing/validation block, aligning the effective supported range here would be a small change with good operational safety benefits.