(mcp) Harden shared HTTP serving against stalled and oversized requests

[tcballard]

Priority

P1 — shared-service availability and memory safety.

Problem

The shared HTTP MCP server accepts and handles one connection synchronously before accepting the next. Request parsing has no read/write deadline, request-line limit, aggregate header limit, or body-size limit, and allocates a buffer directly from Content-Length.

A single client that sends an incomplete request can therefore block the endpoint indefinitely. A large numeric Content-Length can force an arbitrary allocation before request validation.

Evidence

• Serial accept/handle loop
• Blocking unbounded request reader

Reproduction

1. Start decided-mcp --transport http.
2. Open one TCP connection and send only a partial request line or headers.
3. Leave that connection open.
4. Observe that subsequent clients are not accepted or served.

Alternatively, supply an extremely large valid Content-Length and observe allocation is attempted before any configured body cap.

Acceptance criteria

• Slow or incomplete clients cannot prevent the listener accepting other requests.
• Read and write deadlines are enforced.
• Request line, total headers, and body size are capped before allocation.
• Request handling uses bounded concurrency or a bounded worker queue.
• Tests cover slowloris/incomplete requests, malformed lengths, oversized bodies, and saturation.
• Limits and failure responses are documented for operators.