Axum: enforce configurable buffered request-body limits #393

Description

Main still buffers JSON and application/*+json through to_bytes(axum_body, usize::MAX) before core dispatch; see crates/edgezero-adapter-axum/src/request.rs:34. PR #275 replaces the legacy path, and PR #407 adds the configurable buffered JSON cap on the #406 stack. The issue remains an integration/acceptance task, not a request to patch a retired path twice.

Steps to reproduce

Through the real adapter service, send JSON and +json bodies exactly at and one byte above 2,097,152 bytes. Repeat with declared Content-Length, chunked input, an override, and interrupted/erroring reads. Confirm non-JSON bodies remain incremental.

Expected behavior

The accepted JSON buffering path defaults to 2 MiB with an explicit override, counts actual received bytes, returns HTTP 413 on overflow and releases conversion-owned resources.

Impact

Unbounded adapter-owned buffering allows large JSON requests to retain uncontrolled memory. A per-body cap does not establish process-wide memory safety, handler cancellation or concurrency capacity.

Proposed fix

Review/integrate #407 using #275 admission/body mechanisms. Preserve its single cap and typed error/lifecycle mapping. The 2 MiB value aligns with the established Axum buffering default; it is configurable rather than workload certification.

Deferred controls remain separate: active-request limits, body idle/total upload deadlines, handler deadlines/cancellation, total streamed size/lifetime, queues and general overload policy need workload decisions/evidence. No Tokio or blanket Send requirement belongs in portable core.

Done when

• Re-audit the accepted PR feat: implement portable outbound HTTP and request lifecycle contracts #275 implementation and record which checks are already covered. Add only residual changes and missing production acceptance evidence.
• The accepted JSON buffering path is bounded; if feat: implement portable outbound HTTP and request lifecycle contracts #275 removed the legacy eager collection, do not recreate it just to satisfy this check.
• The default is 2 MiB, with an explicit configuration override.
• The limit applies to both application/json and application/*+json.
• Enforcement checks bytes as they arrive, including chunked bodies without Content-Length.
• A body exactly at the limit is accepted; a body one byte beyond it receives HTTP 413 rather than 500.
• Tests cover declared-length and chunked bodies, the configured override, and interrupted/erroring reads. Verify oversized-body status through the adapter service path, not only a conversion helper.
• Rejected or failed collection stops consuming the body and releases conversion-owned resources.
• Non-JSON request bodies remain incremental, with no new total-size or duration restriction.
• Documentation explains that this bounds adapter-owned request-body buffering, not total process memory, handler allocations, or concurrency.

Related

• Parent Make the Axum adapter production-ready for self-hosted deployments #391. Implementation PR Add configurable Axum buffered JSON body limits #407, based on Add Axum production startup and bounded shutdown #406 and feat: implement portable outbound HTTP and request lifecycle contracts #275 / Implement portable outbound HTTP and request lifecycle contracts #436.
• Axum: define a production server lifecycle with bounded graceful shutdown #392 process lifecycle; Axum: preserve incremental streaming with bounded backpressure #394 streaming transport. Axum: enforce configurable buffered request-body limits #393 is not a general admission/deadline framework.
• Axum DefaultBodyLimit.