--web POST body over ~73KB crashes the worker parsing $_POST (heap exhausted, fixed threshold independent of --heap-size)

[mirchaemanuel]

Summary

Under elephc --web, a POST body somewhere past ~73 KB reliably crashes the
worker (heap memory exhausted, empty response) while parsing $_POST,
before the handler ever runs. The threshold is fixed and does not move
with --heap-size (identical at 8 MB and 64 MB, and previously confirmed
unaffected at 256 MB too) — it's an internal limit of the --web form-body
parser, not the application heap.

Environment

• elephc v0.26.0 (release, commit 892ff162), macOS ARM64
• PHP (php -S): the same request returns a normal 413 response instead
  of crashing

Minimal reproduction

<?php
if (isset($_SERVER['REQUEST_METHOD'])) {
    header('Content-Type: text/plain');
    $body = (string) ($_POST['body'] ?? '');
    echo 'len=' . strlen($body) . "\n";
}

POST application/x-www-form-urlencoded, single field, single worker.

Bisection

body (bytes)	heap 8 MB (default)	heap 64 MB
72 000	200 OK	200 OK
74 000	worker dies (heap exhausted, empty response)	worker dies

The threshold is the same (~73 KB) at 8 MB and 64 MB heap (256 MB
previously verified to make no difference either). The worker dies before
the handler runs — any application-level body-size check never gets a
chance to execute — and the master respawns it, so the server stays up but
that one request gets an empty response (curl exit 52).

This is a sharper repro of a milder symptom noted earlier: a ~300 KB POST
body produces the same heap memory exhausted fatal with the default 8 MB
heap, before any app-level size check runs.

Not fixable at the app level

Mitigation available at the server level: --web binaries support
--max-body-size <bytes>; with --max-body-size 262144, an oversize body
gets a clean 413 from the server before parsing even starts (verified:
300 KB → 413, worker stays alive, next request 200 OK):

./app --listen 127.0.0.1:8080 --workers 2 --max-body-size 262144

There remains a residual gap: a body between ~74 KB and the configured
--max-body-size still passes the server's size gate but crashes the worker
during parsing (empty response instead of the handler running). With an
application-level limit set at or below the ~73 KB internal threshold this
gap is closed in practice, but the underlying parser limit is still a bug.

Expected

Parsing a POST body under --web should not have a fixed internal ceiling
independent of --heap-size that crashes the worker; either the parser
should scale with the configured heap, or it should fail gracefully (matching
--max-body-size's 413 behavior) instead of exhausting memory.

Notes

Found building a pastebin single-binary app (--web) for the Discord
contest, where the application enforces its own 256 KiB paste-size limit —
which this bug prevents from ever being reached for bodies over ~73 KB
unless the server-level --max-body-size gate is also configured.