security: bound downstream request-header admission before callback allocation

[seonghobae]

Valid gateway/security gap

Fresh review of the current pg-erd leaf 0145c455f5010bcff2af96e2293530c4fdf35aa4 and pinned/current Pingora 09696b51bc59315353d96686355861604d0bb48c confirms that request-body and process in-flight budgets are explicit, but downstream request-header resource admission is not yet an edge-owned configurable contract.

This matters before commercial cutover because a callback-only header-size check would occur after Pingora has already buffered and parsed the request header. It can reject an application request, but it cannot honestly be described as a pre-allocation parser/resource bound.

Exact supplier evidence

At pinned/current Pingora 09696b51bc59315353d96686355861604d0bb48c:

• HTTP/1 pingora-core/src/protocols/http/v1/common.rs hard-codes MAX_HEADERS = 256, INIT_HEADER_BUF_SIZE = 4096, and MAX_HEADER_SIZE = 1_048_575 bytes.
• HTTP/1 HttpSession::read_request() grows the parser buffer until that fixed maximum. The source explicitly notes that the maximum-size check happens before a subsequent read, so one already-completed large socket read may have allocated/read beyond the nominal threshold before rejection.
• these HTTP/1 values are supplier constants, not a gateway Admin Config option exposed by the current ProxyHttp callback surface.
• HTTP/2 is a different contract: default_h2_options() applies a decoded header-list limit of 64 KiB and 100 concurrent streams, and H2Options::max_header_list_size can customize the H2 value. Do not claim that the H1 fixed wire/parser cap and H2 decoded-header-list accounting are equivalent byte semantics.

The current CWL Runtime Isolation boundary owns max_request_body_bytes, max_in_flight_requests, and the pg-erd v2 response-body progress lifetime only. MigrationGatewayProxy::request_filter() runs after session.req_header() exists, so adding a semantic header sum there would not close the parser-allocation boundary above.

RED acceptance

1. Keep the current exact supplier constants/API as explicit evidence rather than calling request headers "unbounded"; the gap is operator-controlled and migration-versioned admission below the supplier ceiling, not absence of any supplier ceiling.
2. Prove with real downstream traffic that an HTTP/1 request exceeding a desired commercial header budget can be buffered/parsed before ProxyHttp::request_filter, so a callback-only 431 check is not pre-allocation enforcement.
3. Keep HTTP/2 evidence separate: prove the configured/default decoded header-list limit through the actual server composition before claiming H2 header-budget parity.
4. Do not reduce body/in-flight limits, hide the case behind a front proxy, or rely on Nginx/Traefik remaining in front after cutover.

Required repair boundary

1. Determine whether current Pingora provides a supported server/composition hook that can lower HTTP/1 request-header bytes/count before or during parser buffering, while preserving the existing bounded defaults for HTTP/2. If not, open/advance the supplier path instead of copying mutable Pingora parser source into this repository.
2. Introduce any CWL operator-facing field only as an explicit positive versioned Admin Config contract. Preserve generic v1 and pg-erd v1/v2 behavior unless a deliberate version increment is adopted; no hidden default or semantic reinterpretation.
3. Keep separate invariants for at least HTTP/1 header bytes, HTTP/1 header count, and HTTP/2 decoded header-list size because their supplier accounting differs. Reject impossible/zero/overflow values before listener authority.
4. Add real-listener RED→GREEN acceptance with near-limit success and over-limit failure. For HTTP/1, include many-small-fields and one-large-field cases; for H2, include decoded-list-size behavior once H2 is actually admitted by a later protocol version. Preserve /livez//readyz, low-cardinality telemetry, and independent-route recovery without logging attacker header contents.
5. Use HTTP 431 only where the runtime can reliably produce it without weakening parser/resource safety; a transport/parser rejection before application callback is acceptable if that is the supplier's supported behavior. Do not fabricate a prettier status at the cost of reading more attacker-controlled data.
6. Keep SECURITY.md, THREAT_MODEL.md, API_CONFIG_CONTRACT.md, TEST_STRATEGY.md, OPERABILITY.md, TRD.md, CHANGELOG.md, TRACEABILITY, and docs/product-technical-gap-baseline.md code-current with the exact supplier semantics and protocol scope.
7. Require exact-head fmt/compile/test/clippy/rustdoc/100% owned-production coverage plus realistic failure/concurrency traffic, k6/OCI/security/supply-chain and independent review before merge/release credit.

Responsibility boundary

This is reusable Ingress / Runtime Isolation / HTTP transport resource safety. It does not authorize product auth/business policy, Keyverse identity, Wardnet/EgressWeave decisions, cookie semantics, downstream TLS issuance, H2/H3/QUIC admission, or consumer source changes. Any supplier change must be immutable/provenance-bound and reconciled with .github#1605 before release.

[seonghobae]

Fresh supplier-path result (2026-09-03): current protected cloudflare/pingora main@09696b51bc59315353d96686355861604d0bb48c still has no supported HTTP/1 request-header byte/count admission field on HttpServerOptions or the public composition surface. HttpServerOptions exposes h2c, CONNECT proxying, keepalive request limit, and H2 idle timeout; H1 HttpSession::read_request() still uses private supplier constants MAX_HEADERS=256, INIT_HEADER_BUF_SIZE=4096, MAX_HEADER_SIZE=1_048_575. HTTP/2 remains separately configurable through H2Options::max_header_list_size.

Per Pingora's contributor guidance to discuss non-trivial changes in an issue before a PR, I opened the supplier request: cloudflare/pingora#993 — Expose configurable HTTP/1 request-header parser admission limits. It asks for an unset-compatible public H1 parser/composition option, applies the bound during parser buffering including pipelined-prefix reuse, keeps H1 bytes/count separate from H2 decoded-header-list accounting, and explicitly rejects callback-only enforcement, front-proxy dependency, or vendored mutable parser source as substitutes.

Owner closure order is now: supplier disposition/API on #993 -> immutable released/provenance-bound Pingora capability reconciled with .github#1605 -> CWL versioned Admin Config RED -> parser-phase real-listener GREEN -> exact-head repository/security/performance evidence. Do not add a request_filter() header-size check and call #43 closed; that remains post-parser semantic rejection, not resource admission.

[seonghobae]

Writer-safe documentation projection remains Draft PR #44, stacked directly on #42 exact 0145c455f5010bcff2af96e2293530c4fdf35aa4. Its current exact head is 926253f4b72d764a74e8cb32c639e822234f61b6, an ordinary non-force ahead 13 / behind 0 descendant with the parent as merge base. The effective documentation delta now covers API_CONFIG_CONTRACT.md, ARCHITECTURE.md, CHANGELOG.md, CONTEXT_MAP.md, OPERABILITY.md, SECURITY.md, TEST_STRATEGY.md, THREAT_MODEL.md, TRD.md, UBIQUITOUS_LANGUAGE.md, docs/doctoring/TRACEABILITY.md, and docs/product-technical-gap-baseline.md.

The later projection closes remaining documentation drift without claiming runtime closure: OPERABILITY.md now tells operators that generic v1 and pg-erd v1/v2 have no configurable H1 parser-phase header budget; API_CONFIG_CONTRACT.md explicitly refuses a speculative Admin Config field before a supported supplier hook exists; the product/technical baseline now records fixed Pingora H1 ceilings versus the missing lower operator budget and the #43/#993 dependency; CHANGELOG.md carries that release blocker. The bounded-origin evidence is also code-current as aggregate + backend-tagged + frontend-tagged http_req_duration p95 <20 ms, still only a controlled loopback regression.

#44 still does not fix this issue. Supplier cloudflare/pingora#993 remains the implementation dependency, and runtime/config RED must wait for a supported immutable/provenance-bound parser-phase capability before a later versioned Admin Config and real-listener GREEN. Current #44 exact-head runs are CI 33744467835, bounded-origin 33744467831, and Supply Chain 33744467896; their jobs remain pre-checkout queued with steps=[] and no runner identity, so they are control-plane evidence rather than a #43 source failure. Fresh review was requested specifically for 926253f4...; predecessor CodeRabbit coverage does not transfer.

[seonghobae]

Execution successor remains Draft #72 at current exact 5098409da99b22e014f54b1268996c55aa75c514, based on final #44 c026e1c8f419c6c5035a36518c3d482dfe7ff8a8 and changing only tests/h1_header_admission.rs.

The real-socket fixture covers separate byte/count admission cases below Pingora's fixed supplier ceilings. It requires the candidate to be rejected before both the production ProxyHttp application lifecycle and raw origin. Review found and repaired two evidence flaws rather than weakening the oracle: the origin observation window starts only after listener/readiness proof, and exact current captures/drains stdout+stderr while using the payload-free GatewayProxy::logging() lifecycle observation so callback-only local rejection cannot create false GREEN. Both review threads are resolved after static re-verification.

Hosted exact-head execution is currently blocked before that semantic oracle runs. CI 34384092020 attempts 1–3 and bounded-origin 34384091936 attempts 1–3 repeatedly fail the inherited Install native dependencies step before Rust or traffic execution. Attempt-3 decoded log for fresh ubuntu-24.04 job 102581202693 establishes the RCA: apt-get update fails on the runner's preinstalled, unused Google Chrome source https://dl.google.com/linux/chrome-stable/deb with Packages.gz Hash Sum mismatch (expected SHA-256 233e56de019b57db89238fa7bcc3647718dbbea3a40c2dc1c633a8c8952aa9e9, received bc1428ab27c6d76ee9bb76de07f1ded0ddb4aaabd958fc72855634ef5894a4b3) and exits 100. Ubuntu archive/security indexes were not the failing source. Same-head Supply Chain 34384092012 is GREEN and OCI runtime is GREEN through both admitted images, including successful Debian native-dependency installation.

This Actions/provider-image defect has been routed to canonical organization CI owner .github#712 comment 5606428681 with fail-closed acceptance: constrain native dependency provisioning to required OS/package authorities or deterministically disable only unused preinstalled third-party sources; never ignore apt failure, disable integrity/TLS checks, hide it behind retries, or churn product source. The Pingora lane will consume the released/exact-SHA central reusable repair instead of duplicating CI authority locally. Until then no semantic #72 parser RED, load result or capacity GREEN is credited.

Upstream #993 has a current-main contributor candidate, cloudflare/pingora#1000 at observed exact 0171494283c6cbb13dc448c0e242d415ee0f6e08. It remains open/non-draft/mergeable, with build and Semgrep GREEN but no submitted formal review, and is evidence only until maintainer integration/release. Downstream review identified four repair points before promotion: reject/define byte limits above the old MAX_HEADER_SIZE, reject rather than silently clamp header counts above MAX_HEADERS, invoke configuration validation on the supported activation path, and prove the multi-read path bounds buffer/read amplification at a lowered byte budget. These findings remain on #1000 and mirrored to #993.

Keep #43 open. Future progression is .github#712 central native-dependency repair → unchanged #72 parser/application/origin RED → #1000 (or equivalent) contract repair + maintainer integration → release-qualified supplier → explicit positive versioned Admin Config transition if CWL exposes it → unchanged #72 parser/application/origin GREEN + near-limit/default/multi-read/pipelined-prefix coverage. No callback-only 431, local supplier fork, mutable contributor pin, package-integrity suppression, gate weakening, or legacy-proxy retention receives closure credit.