Feature request: esp_http_server support for streaming request bodies larger than 4 GiB (IDFGH-18262)

Is your feature request related to a problem?

We are building an ESP32-P4 application that accepts browser uploads of large files and streams them to an SD/TF card using exFAT. These files can exceed 4 GiB. Storage uses FatFs APIs with 64-bit file sizes, and the HTTP upload path uses bounded buffers (24 KiB per buffer), so the full request body never needs to fit in RAM.

Our local ESP-IDF 6.0.2-based application stopped two uploads of a file larger than 4 GiB at approximately 447 MB. Investigation found that http_parser has a 64-bit content_length, but httpd_req_t.content_len and the internal remaining_len are size_t (32 bits on P4). A body of 4 GiB + 447 MiB therefore truncates to 447 MiB. We have not yet confirmed the original file's exact byte size, so the precise correspondence to that observation is still unverified.

We saw that upstream already addresses this truncation in commit https://github.com/espressif/esp-idf/commit/9d3f510c7f4489c4524ec0b367368bdecd19df8a by rejecting Content-Length > UINT32_MAX with HTTP 413. This request is for supported large-body streaming, not a duplicate report of the truncation bug or a request to simply remove that validation.

Describe the solution you'd like.

Support receiving a known-length HTTP request body larger than 4 GiB through repeated, bounded httpd_req_recv() calls, with full-width length accounting throughout parsing, synchronous/asynchronous request handling, and unread-body cleanup.

We would appreciate maintainer guidance on the preferred API design:

• Widen the public content_len field to uint64_t in an appropriate release, with migration guidance; or
• Provide an explicit opt-in large-body API that preserves existing handlers' behavior and rejects oversized bodies unless the handler can account for them safely.

Changing the public field directly affects structure layout and existing applications' format strings and length variables. We do not assume that a direct type change is acceptable as a stable-release bug fix. The current rejection behavior should remain in place wherever large-body handling is not supported.

Per-call buffer sizes can remain size_t; the requested capability is a 64-bit total and remaining body length, not larger allocations.

Describe alternatives you've considered.

Split the upload into multiple application-level requests below the server limit, with offsets and resumable-upload state. This is a viable workaround, but requires changes to the client/server upload protocol rather than allowing a browser to POST a single File/Blob.

We also prototyped a local SDK patch that widens both HTTP server length fields, compares the parser's unknown-length sentinel without narrowing to int, and uses 64-bit length logging. Our application's upload counters were widened as well. This demonstrates a possible implementation direction, but it has not been prepared as an upstream-compatible API change.

Additional context.

Target: ESP32-P4, Ethernet, SDMMC/exFAT storage.

Validation performed on the local prototype:

• Ethernet application firmware builds successfully.
• A host regression harness uses the actual IDF HTTP parser and field types/assignment extracted from the patched server source, with 32-bit size_t modeled explicitly.
• Boundary cases include 4 GiB - 1, 4 GiB, 4 GiB + 1, 4 GiB + 447 MiB, 8 GiB - 1, 8 GiB, and a request without Content-Length.
• The harness checks parsed lengths and simulated bounded receive accounting; it does not exercise the actual server socket receive path.

We have not yet flashed the prototype or completed a real >4 GiB upload with content verification. Upstream-ready tests would also need to cover actual httpd_req_recv(), asynchronous requests, partial-body cleanup, and a subsequent request on a persistent connection.

Would large known-length request bodies be in scope for esp_http_server, and which compatibility approach would you prefer for a contribution?