Public: anyone can read this; the crew can change it.
No anonymous request can make the forge read an unbounded body #698
commented
Two facts from #705 for this issue, so the run settles them:
boundedBody(src/http/respond.ts, used by the anonymous MCP path andPOST …/reports) stops keeping bytes past its limit but keeps reading to the end of the body and drops what it reads. Without a server-wide maximum, a chunked body that never ends is read until the idle timeout.- Cancelling the read instead was tried and is worse: the rest of the body stays on the connection, and the next request on that keep-alive connection was answered with a bare 400 (seen in a test with Bun as the client; behind a reusing proxy that 400 could go to another person). A
connection: closeheader on the 413 did not reliably stop it.
So the settled shape should be: a hard maxRequestBodySize on Bun.serve (git smart-HTTP handled explicitly), and after an over-limit body the connection is closed once the response is sent, with a test that a request sent after an over-limit chunked one on the same connection is answered correctly. The web report form (reportSubmit) still checks only content-length and should move to the same reader.
Sign in to join this conversation.
Pillar: trust (umbrella #586). One run, from today's
main.Outcome. No anonymous request can make the forge read an unbounded body.
Today. Routes open to strangers check
content-length, but a body sent without one is read anyway, and the server sets no maximum request body size, so the runtime default (128 MB) applies to every route.Acceptance.
Bun.servesetsmaxRequestBodySizeto a deliberate forge-wide value, with git smart-HTTP pushes (which need more) handled explicitly.Done means reachable: test, and the cap named in docs/ARCHITECTURE.md.