feat(http): add SizeLimitHandler to enforce request body size limit by bladehan1 · Pull Request #6658 · tronprotocol/java-tron

bladehan1 · 2026-04-08T08:46:00Z

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. Oversized requests are rejected with HTTP 413 before the body is fully buffered into memory.

Introduce node.http.maxMessageSize and node.jsonrpc.maxMessageSize as independent, configurable size limits
Default: GrpcUtil.DEFAULT_MAX_MESSAGE_SIZE (4 MB), consistent with gRPC defaults
Wire SizeLimitHandler into HttpService.initContextHandler() as the outermost handler
Each HttpService subclass (4 HTTP + 3 JSON-RPC) sets maxRequestSize from the corresponding config getter
Deprecate Util.checkBodySize() — retained as fallback for backward compatibility

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:

Early rejection — oversized requests are stopped before reaching servlet code
Streaming enforcement — limits are enforced during read, not after full buffering
Unified coverage — all HTTP and JSON-RPC endpoints are protected by a single mechanism
Independent tuning — operators can configure HTTP and JSON-RPC limits separately

Closes #6604

This PR has been tested by:

Unit Tests (SizeLimitHandlerTest: boundary, independent limits, UTF-8 byte counting)
Unit Tests (ArgsTest: default value alignment)

Follow up

Remove Util.checkBodySize() callers in a follow-up PR once this is stable
Compression bomb (gzip decompression) protection is a separate concern, tracked independently

Extra details

Files changed: 14 (+253 / -2)

Component	Changes
`HttpService`	Add `maxRequestSize` field, wire `SizeLimitHandler` in `initContextHandler()`
`Args` / `ConfigKey` / `CommonParameter`	Parse `node.http.maxMessageSize` and `node.jsonrpc.maxMessageSize`
7 service subclasses	Set `maxRequestSize` from protocol-specific getter in constructor
`Util.checkBodySize()`	Mark `@Deprecated`
`SizeLimitHandlerTest`	New: 8 tests covering HTTP/JSON-RPC limits, boundary, UTF-8, independence
`ArgsTest`	Align assertions with 4 MB defaults

…imit Add SizeLimitHandler at the Jetty server level to reject oversized request bodies before they are fully buffered into memory. This prevents OOM attacks via arbitrarily large HTTP payloads that bypass the existing application-level Util.checkBodySize() check (which reads the entire body first) and the JSON-RPC interface (which had no size validation).

Introduce node.http.maxMessageSize and node.jsonrpc.maxMessageSize to allow HTTP and JSON-RPC services to enforce separate request body size limits via Jetty SizeLimitHandler, decoupled from gRPC config. - Default: 4 * GrpcUtil.DEFAULT_MAX_MESSAGE_SIZE (16 MB) - Validation: reject <= 0 with TronError(PARAMETER_INIT) at startup - Each HttpService subclass sets its own maxRequestSize in constructor - SizeLimitHandlerTest covers independent limits, boundary, UTF-8 bytes

xxo1shine · 2026-04-08T10:23:05Z

@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 · 2026-04-08T10:47:31Z

@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.

lxcmyf · 2026-04-09T04:23:00Z

framework/src/main/java/org/tron/core/services/http/Util.java

    }
  }

+  @Deprecated


Marking this helper as deprecated does not make the new HTTP limit effective yet. PostParams.getPostParams() and many servlets still call Util.checkBodySize(), and that method is still enforcing parameter.getMaxMessageSize() (the gRPC limit), not httpMaxMessageSize. So any request whose body is > node.rpc.maxMessageSize but <= node.http.maxMessageSize will pass Jetty and then still be rejected in the servlet layer, which means the new independent HTTP setting is not actually honored for a large part of the API surface.

Good catch, thanks. checkBodySize() has been updated to use parameter.getHttpMaxMessageSize() instead of parameter.getMaxMessageSize(), so the servlet-layer fallback now honors the independent HTTP limit. See the latest push.

lxcmyf · 2026-04-09T04:25:04Z

framework/src/main/java/org/tron/common/application/HttpService.java

    ServletContextHandler context = new ServletContextHandler(ServletContextHandler.SESSIONS);
    context.setContextPath(this.contextPath);
-    this.apiServer.setHandler(context);
+    SizeLimitHandler sizeLimitHandler = new SizeLimitHandler(this.maxRequestSize, -1);


This moves oversized-request handling in front of every servlet, so those requests never reach RateLimiterServlet.service() / Util.processError(). Today the HTTP APIs consistently set application/json and serialize failures through Util.printErrorMsg(...); after this change an over-limit body gets Jetty's default 413 response instead. That is a client-visible behavior change for existing callers, and the new test only checks status codes so it would not catch the response-format regression.

Thanks for flagging the response-format difference. I did a detailed comparison:

Before (checkBodySize rejection):

HTTP status: 200 OK (processError() does not set status code)

Body: {"Error":"java.lang.Exception : body size is too big, the limit is 4194304"}

After (SizeLimitHandler rejection):

HTTP status: 413 Payload Too Large

Body: Jetty default error page (non-JSON)

The format is indeed not fully compatible, but I believe this is acceptable:

The existing behavior is itself incorrect — returning 200 OK with an error JSON body violates HTTP semantics. Clients that only check status codes would incorrectly treat the oversized request as successful. The new 413 is the proper HTTP response for this scenario.

The trigger threshold is very high — default is 4 MB. Normal API requests are far below this. Only abnormal or malicious payloads hit this limit, so the impact surface is negligible for legitimate clients.

413 is a standard HTTP status code — all HTTP client libraries handle it correctly. Clients already need to handle non-JSON infrastructure errors (e.g., Jetty 503, proxy 502/504).

The new layer provides a real security benefit — SizeLimitHandler rejects during streaming, before the body is fully buffered into memory, which is the core OOM protection. Falling back to application-layer formatting would defeat this purpose.

checkBodySize() was enforcing maxMessageSize (gRPC limit) instead of httpMaxMessageSize, causing the independent HTTP size setting to be ineffective at the servlet layer. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

waynercheung · 2026-04-09T11:09:22Z

framework/src/main/java/org/tron/common/application/HttpService.java

    ServletContextHandler context = new ServletContextHandler(ServletContextHandler.SESSIONS);
    context.setContextPath(this.contextPath);
-    this.apiServer.setHandler(context);
+    SizeLimitHandler sizeLimitHandler = new SizeLimitHandler(this.maxRequestSize, -1);


SizeLimitHandler only guarantees a pre-servlet 413 when Content-Length is known. For chunked / unknown-length requests, enforcement happens while downstream code is reading the request body. In the current codebase many HTTP handlers catch broad Exception around request.getReader(), and RateLimiterServlet also catches unexpected Exception, so the streaming over-limit exception can be absorbed before Jetty turns it into a 413. That means the PR still does not prove the “uniform 413” behavior described in the issue for requests without Content-Length.

waynercheung · 2026-04-09T11:11:00Z

framework/src/test/java/org/tron/common/jetty/SizeLimitHandlerTest.java

+    Assert.assertEquals(200, post(httpServerUri, new StringEntity("small body")));
+  }
+
+  @Test


these tests all use StringEntity, so they exercise the fixed-length / Content-Length path only. They do not cover chunked or unknown-length requests, where SizeLimitHandler enforces during body reads instead of before servlet dispatch. Since the existing servlet chain has broad catch (Exception) blocks, we need at least one end-to-end test for the streaming path against a real HTTP servlet and the JSON-RPC servlet, and it should assert that an oversized request still surfaces as HTTP 413

waynercheung · 2026-04-09T11:12:28Z

framework/src/main/java/org/tron/core/config/args/Args.java

+    int defaultHttpMaxMessageSize = GrpcUtil.DEFAULT_MAX_MESSAGE_SIZE;
+    PARAMETER.httpMaxMessageSize = config.hasPath(ConfigKey.NODE_HTTP_MAX_MESSAGE_SIZE)
+        ? config.getInt(ConfigKey.NODE_HTTP_MAX_MESSAGE_SIZE) : defaultHttpMaxMessageSize;
+    if (PARAMETER.httpMaxMessageSize <= 0) {


The new config validation rejects non-positive values, but extremely large limits are still accepted silently. I don’t think a hard cap is mandatory, but at least warning on suspiciously large values would make misconfiguration easier to catch.

bladehan1 added 7 commits March 19, 2026 15:21

feat(http) : wait for HttpService startup future in SizeLimitHandlerTest

736f2ed

opt(checkstyle): optimize checkstyle

c41d30e

change(config): update default size

321e26a

test(framework): align ArgsTest with 4M defaults

e6b11a3

test(http): doc for default value

674e547

bladehan1 requested review from 0xbigapple, 317787106, Sunny6889, kuny0707, lvs0075, lxcmyf, waynercheung and xxo1shine as code owners April 8, 2026 08:46

kuny0707 removed request for 317787106, kuny0707, lvs0075, lxcmyf and xxo1shine April 9, 2026 04:21

lxcmyf reviewed Apr 9, 2026

View reviewed changes

halibobo1205 added this to the GreatVoyage-v4.8.2 milestone Apr 9, 2026

halibobo1205 added topic:api rpc/http related issue Improvement labels Apr 9, 2026

bladehan1 force-pushed the feat/request_size branch from 24abc3a to 3048750 Compare April 9, 2026 10:43

waynercheung reviewed Apr 9, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

feat(http): add SizeLimitHandler to enforce request body size limit#6658
bladehan1 wants to merge 8 commits intotronprotocol:developfrom
bladehan1:feat/request_size

bladehan1 commented Apr 8, 2026

Uh oh!

xxo1shine commented Apr 8, 2026

Uh oh!

bladehan1 commented Apr 8, 2026

Uh oh!

lxcmyf Apr 9, 2026

Uh oh!

bladehan1 Apr 9, 2026

Uh oh!

lxcmyf Apr 9, 2026

Uh oh!

bladehan1 Apr 9, 2026

Uh oh!

waynercheung Apr 9, 2026

Uh oh!

waynercheung Apr 9, 2026

Uh oh!

waynercheung Apr 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Conversation

bladehan1 commented Apr 8, 2026

Uh oh!

xxo1shine commented Apr 8, 2026

Uh oh!

bladehan1 commented Apr 8, 2026

Uh oh!

lxcmyf Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

bladehan1 Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

lxcmyf Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

bladehan1 Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

waynercheung Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

waynercheung Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

waynercheung Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants