MAX_REQUEST_BYTES: spec says 10MB, both implementations enforce 1MB

[Yatsuiii]

docs/spec/proxy-security.md:39 specs MAX_REQUEST_BYTES = 10 * 1024 * 1024 # 10MB.

Both implementations enforce 1MB:

• scripts/mock_upstream.py, MAX_REQUEST_BYTES = 1_000_000
• src/cmcp_runtime/mcp/server.py, _DEFAULT_MAX_REQUEST_BYTES = 1_000_000, used as the max_request_bytes default on MCPServer.__init__

An order of magnitude apart, and nothing in the repo records which one is intended. I raised this on #562 while implementing MAX_STRING_LENGTH and deliberately didn't pick a side, but #562 was closed as completed by #570, so the question isn't tracked anywhere now. Opening this so it isn't lost.

The two readings lead opposite ways:

• 1MB was a deliberate tightening, and the spec is stale. Fix the document.
• 1MB is drift, and implementations should be raised toward 10MB. Fix the code, and note that widening a DoS bound is not a change to make quietly.

I don't have evidence for either. The spec is Draft v0.1 and its git history doesn't say where 10MB came from.

Two things that depend on the answer, so it's worth settling rather than leaving:

MAX_STRING_LENGTH is now derived from whatever body cap is enforced (#570, and #572 makes the spec say so), which removes the dead-code hazard at either value. So this doesn't block that. But the derived cap moves with the body cap, and a jump from 1MB to 10MB moves the per-string cap from 500KB to 5MB, which is a real change in what the gateway accepts rather than a documentation cleanup.

MAX_JSON_NESTING_DEPTH and MAX_PARSE_TIME_MS are still unimplemented. Whoever implements them will size them against a body cap, and picking against the wrong one bakes the mismatch in further.

Happy to send whichever patch the answer implies. I don't think it's a contributor's call to make.

[imran-siddique]

1MB stands. The spec is stale. Fix the document, not the code.

This is not a judgement between two defensible numbers, and I am glad you did not pick a side, because there is a record and it settles it.

cmcp#147, filed and closed 2026-06-06, is the DOS-001 origin issue. It ends:

Fix: add a MAX_REQUEST_BODY = 1 MB cap before reading the body.

So 1MB is the value specified when the control was created, in the security issue that created it. The implementations are the decision; the document is what was never updated. docs/spec/proxy-security.md had its status header written on 2026-06-04, two days before that issue, which puts the 10MB on the wrong side of the decision.

There is a second tell, and it is the one I would have used had #147 not existed. Both implementations write 1_000_000, decimal. The spec writes 10 * 1024 * 1024, binary. Two independent implementations agreeing on a decimal value while the document uses a binary one is what a deliberate choice looks like; drift from a document tends to preserve its arithmetic.

Why 1MB is also the right answer on the merits, not just the record. Raising a DoS bound is not a documentation cleanup, as you said yourself. The cap runs pre-authentication, so it bounds what an unauthenticated caller can make the gateway buffer, and a JSON-RPC tool call that legitimately needs more than a megabyte should be carrying a reference rather than a payload. Widening it tenfold would need an argument, and nobody has made one.

Please send the documentation patch. Change MAX_REQUEST_BYTES in docs/spec/proxy-security.md to 1_000_000, matching the enforced form rather than restating it in binary, and add a line recording that it comes from DOS-001 with a pointer to #147. The provenance is the part that stops this recurring: the reason it drifted is that the number appeared in the document with nothing saying where it came from.

Your two downstream points are both right and both now answered. The derived MAX_STRING_LENGTH stays at 500KB. And whoever implements MAX_JSON_NESTING_DEPTH and MAX_PARSE_TIME_MS sizes them against 1MB, which is worth stating in the same patch so the next person does not re-derive it from the stale figure.

Thank you for opening this rather than letting it disappear when #562 closed. A question that was raised, deliberately left open, and then lost because its parent issue completed is exactly the kind that resurfaces two years later as a production incident.