glm-5.3-flash
e2c255d40c
Decomposition of docs/reviews/002-post-remediation-review.md per its 5-unit remediation plan: - Unit 1 (security-critical): gw15-publish-body-cap, prj16-schema-via-call (CF-004 filed alkcall-side), fwd13-dot-segments, fwd16-missing-capability, oai11-ref-memoization - Unit 2 (timeout/terminality): ws13-idle-progress, fwd15-stream-timeout, cli01-retry-after-budget, con17-mcp-pagination, con18-wss-sweep-exit - Unit 3 (projection/docs): projection-truthfulness, mcp-batch-cap, gw16-status-drift - Unit 4 (spec-import): yaml-normalization, oai13-path-item-wildcards, import-loudness-cluster, js01-placeholder-check, fwd17-19-contract-decisions - Unit 5 (WS polish + tests): con18b-ws-polish, client-policy-wire-tests, cov-deployment-knobs, cov13-dead-code, srv11-srv12-router-ordering - review-002-bracketed-followup: tentatively planned post-bulk pass (stale-check, OQA-18 enforcement decision, CON-08/09 close() lever, cross-crate re-checks) — deliberately not serialized against the bulk Also: review-002 numbering repair (CON-14 was double-booked; MCP pagination now CON-14, from_wss monitor renumbered CON-18, missing CON-14 section added). taskgraph: 66 valid, no cycles; 24 pending (all review-002); gen-1/gen-2 parallel waves identified; workflow-cost hotspots are prj16 (12.8) and ws13 (11.1), both carrying the reviewed slicing guidance in their Notes.
77 lines
3.5 KiB
Markdown
77 lines
3.5 KiB
Markdown
---
|
|
id: review-002-gw15-publish-body-cap
|
|
name: Cap /publish body buffering pre-newline + explicit body-limit layer (GW-15)
|
|
status: pending
|
|
depends_on: []
|
|
scope: moderate
|
|
risk: medium
|
|
impact: component
|
|
level: implementation
|
|
tags: [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. |