alkhttp/tasks/gateway/review-002-gw15-publish-body-cap.md

id, name, status, depends_on, scope, risk, impact, level, tags

id	name	status	depends_on	scope	risk	impact	level	tags
review-002-gw15-publish-body-cap	Cap /publish body buffering pre-newline + explicit body-limit layer (GW-15)	pending		moderate	medium	component	implementation	gateway review-002 security

Description

Review 002 GW-15 [major] — /publish lost both claimed memory bounds in the GW-06 streaming rewrite. Verified at tree 91483a7:

1. No body limit on the route. publish_handler takes raw axum::body::Body (src/gateway/routes.rs:249-253). axum's 2 MiB DefaultBodyLimit is a request extension consulted only by extractors (axum-core request_parts.rs returns the raw body untouched) — a raw-Body handler has no default limit. The module doc's claim ("in addition to axum's own 2 MiB default body limit") is false on this route.
2. Unbounded line buffer. BufferedLines::next_line (routes.rs:425-448) enforces MAX_PUBLISH_LINE_BYTES only when a \n is found; bytes accumulate in self.buffer unboundedly until then, and the trailing-EOF std::mem::take(&mut self.buffer) path has no cap check at all.

Concrete failure: unauthenticated POST /publish with chunked transfer-encoding streaming 'a' forever (no newline) → heap grows with the upload until OOM; each poll also re-scans the whole buffer from index 0 → O(n²) CPU on top. This is the SRV-03 class one route over (SRV-03 fixed /mcp; /publish regressed into the same class via the streaming rewrite).

Acceptance Criteria

• BufferedLines errors (terminal LineError::LineCap → the same INVALID_INPUT family the line-cap error uses today) once self.buffer.len() > MAX_PUBLISH_LINE_BYTES, checked before extending, even with no newline seen — the trailing-EOF mem::take path cannot exceed the cap
• The publish route (or the whole gateway router) carries an explicit request-body-limit layer so it does not depend on extractor-side defaults for raw-Body handlers (size = the 2 MiB convention; note in module doc)
• Wire test: chunked upload with no "\n" for > cap bytes is rejected with the documented status/body (not 200, not OOM)
• Wire test: EOF without newline after > cap buffered bytes also rejected (the mem::take path)
• Existing publish tests still pass (first-line handling, NDJSON streaming, schema validation, caps on terminated lines)
• cargo test, cargo clippy --all-targets -- -D warnings, cargo fmt --check pass

References

• docs/reviews/002-post-remediation-review.md (Part C', GW-15; Part G', COV-12 BufferedLines hot spot)
• docs/architecture/decisions/068-gateway-publish-endpoint.md
• src/gateway/routes.rs:249-253 (handler), 395-470 (BufferedLines)
• tasks/gateway/review-001-publish-schema-validation-robust.md (the cache this must not stale)

Notes

The line-cap test that exists today (publish_line_exceeding_cap…) short-circuits at the route level in single-chunk delivery — the new pre-extend check must be exercised with a streamed (multi-chunk, never-newline) body, which is the shape the old test cannot see. Keep MAX_PUBLISH_LINE_BYTES as the single cap constant; a separate total cap is optional (the layer limit bounds the total once landed).

GW-16 (the 400-vs-422 drift on the cap error's status) is deliberately NOT in scope here — see review-002-gw16-status-drift; land the cap with today's status first, then normalize statuses in that task to avoid churn in the same lines.