Aias00 opened a new issue, #7816: URL: https://github.com/apache/shenyu/issues/7816
### Is there an existing issue for this? - [x] I searched existing issues for requestMaxSize and chunked request size limits. Reports about codec aggregation returning 413 are different from this rule-level limit not being applied. ### Current Behavior A positive divide rule `requestMaxSize` is enforced only when the request supplies Content-Length. For a normal chunked/unknown-length request, Spring returns -1 for that header, and the comparison succeeds without examining actual body bytes. A minimal probe using the built DividePlugin and actual rule/upstream caches produced: ```text knownLength=true declaredLength=2 limit=1 forwarded=0 forwardedBytes=0 knownLength=false declaredLength=-1 limit=1 forwarded=1 forwardedBytes=2 ``` Both requests contain the same 2-byte body. Only the unknown-length request supplies Transfer-Encoding: chunked instead of Content-Length. ### Expected Behavior The configured rule-level requestMaxSize should apply to actual request size regardless of HTTP framing. A request exceeding a 1-byte limit should be rejected for both known-length and chunked input. ### Reproduction 1. Populate a divide rule with `requestMaxSize=1`, `retry=0`, and a reachable upstream (or a recording downstream chain). 2. Send a POST with Content-Length: 2 and a 2-byte body. The divide size check prevents downstream execution. 3. Send the same body as a chunked request without Content-Length. The divide plugin executes the downstream chain, which receives 2 bytes despite the 1-byte limit. The probe invoked the actual DividePlugin.doExecute with Spring MockServerWebExchange, a real DividePluginDataHandler rule cache and UpstreamCacheManager, and a recording downstream chain that consumed/counts/releases the body. It ran in a separate JVM against the current built distribution; it did not modify the running cluster. ### Code Evidence [DividePlugin.java:89–95](https://github.com/apache/shenyu/blob/04f7c2e8b7d282f14510157a9ab0bfaab538ecac/shenyu-plugin/shenyu-plugin-proxy/shenyu-plugin-divide/src/main/java/org/apache/shenyu/plugin/divide/DividePlugin.java#L89-L95): ```java if (ruleHandle.getRequestMaxSize() > 0) { if (exchange.getRequest().getHeaders().getContentLength() > ruleHandle.getRequestMaxSize()) { // reject } } ``` The normal Netty proxy path with retry=0 streams the body and does not apply a corresponding cumulative byte limit. `spring.codec.max-in-memory-size` protects codec aggregation; it does not establish this rule-specific limit for arbitrary proxy streams. A separate ingress limit may bound a particular deployment, but would not implement the divide rule's configured value. ### Suggested Fix / Regression Coverage Retain the early Content-Length check and also enforce the byte budget while consuming unknown-length bodies. Reject/release excess buffers and cancel forwarding appropriately; avoid unbounded aggregation as a replacement. Test exact-limit, over-limit, unknown-length and cancellation cases, as well as ordinary known-length requests. ### Environment Apache ShenYu `2.7.2-SNAPSHOT`, master `04f7c2e8b7d282f14510157a9ab0bfaab538ecac`; Java 17; Netty HTTP transport; divide retry=0. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
