[Feature] Unified HTTP Request Body Size Limit

[bladehan1]

Problem Statement

　　The current HTTP service layer of java-tron lacks a unified pre-ingress limit for request body size. The issues include: lack of early rejection; validation only occurs after the full request body is read (post-read validation); risk of memory amplification, where oversized requests consume memory even if ultimately rejected; scattered validation logic (e.g., JSON-RPC and broadcasthex use Util.checkBodySize, leading to inconsistent implementation and easy omission); inconsistency between HTTP and gRPC behavior (gRPC already has maxInboundMessageSize, while HTTP lacks an equivalent mechanism).

Proposed Solution

　　Introduce a unified HTTP body pre-ingress limit at the Jetty layer to enable early rejection, align with gRPC limit strategies, and provide independent configuration capabilities for HTTP and JSON-RPC.

Specification

　　Core mechanism: Introduce a SizeLimitHandler at the top of the Jetty handler chain, performing size checks during streaming (streaming enforcement). Requests exceeding the limit are rejected immediately without entering the application layer.
　　Unified configuration: Introduce node.http.maxMessageSize and node.jsonrpc.maxMessageSize, which apply independently to HTTP and JSON-RPC respectively; gRPC continues to use node.rpc.maxMessageSize, and the three are independent of each other; the default values of the two new configuration items are set to 4 times node.rpc.maxMessageSize, as HTTP request bodies are generally 2–6 times larger than JSON-RPC, and the average is used here.
　　Application layer adjustment: Remove body size validation responsibility from the application layer; retain Util.checkBodySize as deprecated for compatibility.

API Changes (if applicable)
　　Requests exceeding the limit will uniformly return 413 Payload Too Large, no longer relying on application-layer handling.

Configuration Changes (if applicable)
　　New configuration items: node.http.maxMessageSize, node.jsonrpc.maxMessageSize; node.rpc.maxMessageSize remains unchanged and is only used for gRPC.

Scope of Impact

Breaking Changes
　　Requests exceeding the configured protocol limits (node.http.maxMessageSize or node.jsonrpc.maxMessageSize) will be rejected early (413), and calls relying on large request bodies will no longer be available; mitigation: adjust configurations or split requests.

Backward Compatibility
　　Behavior is controlled independently per protocol configuration, allowing flexible operational tuning; Util.checkBodySize is temporarily retained (deprecated).

Implementation

Do you have ideas regarding the implementation?
　　Implementation: Construct SizeLimitHandler in HttpService.start() or its subclass methods. Select the corresponding limit based on request path or entry type (HTTP uses node.http.maxMessageSize, JSON-RPC uses node.jsonrpc.maxMessageSize), and insert it at the very beginning of the handler chain; it must execute before servlet/filter, enforce streaming processing to avoid full buffering, and intercept at an early connection stage.

Are you willing to implement this feature?
　　Yes.

Estimated Complexity
　　Low → Medium, changes are concentrated at the HTTP ingress layer, involving multi-entry limit selection logic with controllable risk.

Testing Strategy

Test Scenarios
　　Oversized requests: HTTP > node.http.maxMessageSize or JSON-RPC > node.jsonrpc.maxMessageSize → return 413, do not enter application layer, no significant memory growth; normal requests are unaffected; JSON-RPC is independently controlled by node.jsonrpc.maxMessageSize; stress test with continuous large requests to verify stable memory usage without amplification.

Performance Considerations
　　Streaming-based enforcement avoids full loading, reduces memory allocation compared to application-layer validation, lowers GC pressure, and improves DoS resistance.

Alternatives Considered (Optional)

　　Per-endpoint application-layer validation: high redundancy, easy to miss, cannot prevent memory amplification; Servlet Filter: executed too late, cannot intercept at the connection layer; single unified configuration: cannot satisfy independent governance requirements across different protocols.

Additional Context (Optional)

　　Essentially ingress hardening: validate after read → reject before read, scattered logic → centralized control, application-layer fallback → container-layer protection; also enables independent governance boundaries across multiple protocols, improving DoS resistance and reducing operational and ecosystem communication costs.

Related Issues/PRs
　　(To be added)

[halibobo1205]

About the default value, 4 * node.rpc.maxMessageSize works out to 16MB, which feels too generous. GET request params are tiny, and for POST, the largest case should be transaction, where TRANSACTION_MAX_BYTE_SIZE = 512KB — even with JSON/hex encoding overhead, that's roughly 1MB at most. A 16MB default is way beyond actual usage and leaves too much room for abuse. Something like 2MB or 4MB should be sufficient.

[Sunny6889]

About the default value, 4 * node.rpc.maxMessageSize works out to 16MB, which feels too generous. GET request params are tiny, and for POST, the largest case should be transaction, where TRANSACTION_MAX_BYTE_SIZE = 512KB — even with JSON/hex encoding overhead, that's roughly 1MB at most. A 16MB default is way beyond actual usage and leaves too much room for abuse. Something like 2MB or 4MB should be sufficient.

I agree with this proposal. It might be worth doing some statistical research on actual request body sizes from real-world traffic before settling on a fixed multiplier of 4x node.rpc.maxMessageSize.

Another practical reference point: check the default body size limits used by popular clients and proxies in the TRON ecosystem (e.g., TronWeb, TronGrid, or common reverse proxies in front of full nodes). Using the most permissive widely-adopted limit as an upper bound would give a data-driven, ecosystem-compatible default value.

[warku123]

Great proposal! Before finalizing the default limit, do we have any data on request body size distribution from production FullNodes? Also, has there been any impact analysis on existing traffic — are there legitimate use cases currently exceeding 2-4MB?

It would be helpful to validate the default value against real-world metrics first to avoid breaking existing use cases.

[bladehan1]

Thanks, agreed.

I also want to avoid making this issue depend on a full request-size study first. In practice, that can easily become a blocking item: it is hard to collect representative data, hard to prove coverage is sufficient, and the discussion may get stuck on methodology instead of solving the ingress-protection problem itself.
So I think the default should be treated as an engineering guardrail, not as a value that must be derived from exhaustive traffic analysis.

The important point here is:

• 16MB looks too permissive for the current HTTP use cases,
• the main goal of this issue is to introduce a unified pre-ingress body limit,
• and the default should be conservative enough to reduce abuse surface, while still covering normal requests.

Based on that, it probably makes more sense to choose a smaller default such as 2MB or 4MB as a practical starting point, and keep it configurable for operators with special workloads.
So I would not treat traffic analysis as a prerequisite for this issue. If such data becomes available later, we can still use it to refine the default, but it should not block introducing the protection itself.

I’m leaning toward 4MB as the revised default for now, mainly as a conservative but not overly restrictive starting point.

[fortuna502]

@bladehan1
Hi, I previously worked on a first cut for this in branch fix/max_post_body.

The idea in that version was:

• add a RequestSizeLimitFilter to the HTTP / JSON-RPC servlet contexts;
• do an early Content-Length pre-check when possible;
• wrap the request InputStream / Reader and enforce the limit while the body is being read;
• return 413 when the limit is exceeded;
• keep Util.checkBodySize as a fallback for compatibility.

After comparing it with the proposal in this issue, I think that implementation is only a partial match to the target
design:

1. It is still a servlet filter / request-wrapper solution, not a top-level Jetty handler.
   That means true early rejection only happens when Content-Length is present; otherwise the limit is enforced
   when downstream code starts consuming the request body.
2. It does not introduce independent configs like node.http.maxMessageSize and node.jsonrpc.maxMessageSize.
   My earlier version used a single fixed limit for the filter, while the legacy application-layer check still
   depended on node.rpc.maxMessageSize.
3. It does not fully remove scattered application-layer validation yet.
   Util.checkBodySize was still kept as fallback, so the logic was not fully centralized.
4. It was more of a first cut for fullnode HTTP / JSON-RPC ingress, not yet the complete unified solution across all
   HTTP entry points.

So I think that branch is useful as a PoC for streaming-based request-size enforcement, but to align with this issue,
the cleaner direction is to move the limit into the Jetty handler chain, make HTTP and JSON-RPC limits independently
configurable, and keep Util.checkBodySize only as a deprecated compatibility fallback.

If that direction makes sense, I can rework the previous implementation toward the handler-based approach described
here.

[bladehan1]

@fortuna502
Thanks for the detailed context — this is very helpful.

Your previous branch sounds like a solid PoC for streaming-based request size enforcement, especially around wrapping the InputStream and enforcing limits during read. I agree with your assessment that the main gap is at the layering: filter/request-wrapper vs a top-level Jetty handler.
Also, on the enforcement timing, I think we are effectively aligned — even in the handler-based approach, for requests without Content-Length the limit is still enforced during streaming consumption, just at a cleaner and more centralized layer.

Based on that, I’ve been moving forward with a handler-based implementation along the lines described in this issue.The core logic is mostly in place on my side, and I’m currently focusing on strengthening tests and edge-case coverage.

That said, your PoC is definitely valuable, and it helped validate the streaming enforcement approach. If you’re interested, it would be great to have your feedback on the handler-based version once I push it — especially around edge cases and behavior consistency.

[lxcmyf]

@bladehan1
Does this limit apply uniformly to all HTTP endpoints, including transaction broadcast APIs such as /wallet/broadcasttransaction or /wallet/broadcasthex?

Some transactions (especially contract deployments) may contain relatively large payloads. If the limit is enforced at the Jetty ingress layer, could this introduce compatibility issues for existing clients unless the default value is carefully tuned?

[fortuna502]

@bladehan1

Thanks, that makes sense.

I agree with your clarification on enforcement timing: for requests without Content-Length, both approaches ultimately enforce the limit during streaming consumption, and the main difference is really the layer where that enforcement lives. Putting it at the Jetty handler level is definitely cleaner from a centralization and maintainability perspective.

Happy to review the handler-based version once you push it. I can focus in particular on edge cases like:

• requests with and without Content-Length
• chunked transfer / streaming reads
• ensuring oversized requests return 413 consistently
• making sure application-layer fallbacks do not create behavior drift
• consistency between HTTP and JSON-RPC limits / config behavior

Please ping me when it is up.