migration: prove release-qualified WebSocket transport before enabling Upgrade

[seonghobae]

Refs #28, #9, #58, #113.

Finding / authority boundary

The current gateway contract remains correctly fail-closed for uncharacterized HTTP/1 Upgrade. This issue owns the future reusable transport acceptance required before any versioned WebSocket enablement. It does not relax #28, enable Upgrade today, copy product authentication/business routing into the gateway, or move Keyverse/Wardnet/EgressWeave authority into transport delivery.

Consumer evidence remains product-owned. ContextualWisdomLab/naruon#1507 is the product-owner path, while pingora-gateway#9 records that one Naruon live-E2E Nginx path forwards WebSocket Upgrade/Connection and uses 600 s read/send timeouts. That does not establish the Kubernetes ingress or Traefik/Keycloak topology, and it does not make 600 s a reusable gateway timeout policy.

Current released-supplier RED is now source-bound and reproducible

The previous gap was not only that Pingora's HTTP/1 fast-101 path was suspected to fail, but that this repository lacked a source-bound real-wire oracle. #113 now closes that characterization gap only.

At exact #113@fbad4e031927b0a92adc7244224d2bfdaba7d513:

• ordinary CI 35431884205: SUCCESS;
• Supply Chain 35431884180: SUCCESS;
• PgErd bounded-origin capacity 35431884182: SUCCESS;
• dedicated WebSocket fast-101 Supplier Characterization 35431884211 / job 105867851370: SUCCESS in expected-RED receipt semantics.

The dedicated job verified exact checkout, proved that the default all-target graph excludes the feature-gated supplier RED, compiled the focused test, and ran only released_pingora_keeps_fast_101_upgrade_tunnel_bidirectional. Released Pingora 0.9.0 then reproduced the bounded post-101 failure client server-frame prefix closed before the frame completed; the focused Rust test result was FAILED exactly as the characterization predicate requires. Artifact 10585145835 (websocket-fast-101-supplier-red-fbad4e031927b0a92adc7244224d2bfdaba7d513) has SHA-256 643e78ee94d3289f69827e3c21aa3651422b62f2804aa6deea7b29c77b0cedb5.

This is not WebSocket capability GREEN. It proves that the unchanged current acceptance reliably fails on released Pingora 0.9.0 while ordinary repository CI remains GREEN.

Fresh supplier authority is still unresolved:

• cloudflare/pingora#946 remains open and describes the same scheduling-sensitive HTTP/1 upgrade teardown when upstream 101 wins against empty request-body completion;
• proposed repair cloudflare/pingora#947@1e8488b0627370831832744fc6e65614396c310d remains open/unmerged and is mutable contributor evidence only;
• protected cloudflare/pingora/main remains 4487f7b2ab50f159e4a2cf4f6a6b813f61bb6e19;
• latest public release remains Pingora 0.9.0, published 2026-09-09, so there is still no later release-qualified supplier identity containing a maintainer disposition for this defect.

Do not pin #947, vendor/copy its patch, weaken #28's Upgrade rejection, or convert the expected-RED receipt into capability/release credit.

Standards boundary

The transport forms remain distinct contracts:

1. HTTP/1.1 WebSocket uses the RFC 6455 opening handshake over HTTP Upgrade. RFC 9931 reinforces that HTTP/1.1 protocol-transition data must not be sent optimistically before the transition is accepted; RFC 6455 already requires the client to wait for the server response before sending WebSocket data.
2. HTTP/2 WebSocket uses RFC 8441 Extended CONNECT on one H2 stream, including SETTINGS_ENABLE_CONNECT_PROTOCOL=1 and :protocol = websocket. HTTP/1 Connection/Upgrade/101 semantics are not the H2 wire contract.
3. HTTP/3 WebSocket uses RFC 9220's adaptation of Extended CONNECT and is a separate QUIC/H3 capability lane.

RFC 9110/9112 remain the HTTP semantics/HTTP/1.1 basis. H2 or H3 capability must never be inferred from HTTP/1 acceptance or generic downstream TLS/H2 support elsewhere in the stack.

Current RED acceptance

1. v1 and current pg-erd versions intentionally reject HTTP/1 Upgrade before origin contact; no released versioned config admits WebSocket.
2. test: reproduce Pingora fast-101 WebSocket tunnel teardown #113 now provides a source-bound, exact-SHA, real-wire fast-101 RED oracle against released Pingora 0.9.0, and that oracle currently fails as expected after the 101 transition.
3. There is still no maintainer-integrated, release-qualified supplier repair that makes the unchanged test: reproduce Pingora fast-101 WebSocket tunnel teardown #113 acceptance GREEN.
4. There is no reusable gateway acceptance yet for long-lived flow, bounded buffering/backpressure, client/origin disconnect propagation in both directions, half-close/abnormal reset, SIGTERM/drain, readiness with admitted tunnels, or payload-safe observability.
5. Naruon E2E evidence does not establish Kubernetes ingress WebSocket behavior, production timeout values, TLS/SNI/certificate ownership, H2 Extended CONNECT, H3, or deployment rollback.
6. HTTP/2 and HTTP/3 WebSocket capability remain independent RED→GREEN contracts.

GREEN acceptance

Only after a maintainer-owned supplier disposition exists in a release-qualified Pingora identity:

1. reconcile the current supplier-characterization lane onto current release ancestry and rerun the unchanged test: reproduce Pingora fast-101 WebSocket tunnel teardown #113 real-wire acceptance against that exact supplier; fast-101 ordering must become GREEN under constrained CPU and realistic concurrency rather than by deleting the oracle, delaying 101 artificially, changing fingerprints, or widening timeouts;
2. add an explicit versioned gateway capability that admits WebSocket only for consumer-derived routes/profiles; omission remains fail-closed and request data cannot select arbitrary tunnel destinations;
3. prove valid 101 followed by bidirectional application frames, plus client-close, origin-close, abnormal reset and half-close behavior with no leaked task/connection, silent replay/failover, unrelated-route poisoning, or unbounded recovery;
4. prove bounded backpressure/flow behavior for long-lived traffic without whole-message buffering, with timeout semantics derived from consumer contracts rather than copied from the Nginx 600 s fixture;
5. prove SIGTERM/drain with admitted tunnels, /livez//readyz, rootless/read-only OCI execution, low-cardinality transport observability, and no payload/cookie/token/customer-data logging;
6. prove HTTP/2 Extended CONNECT separately: SETTINGS_ENABLE_CONNECT_PROTOCOL=1, correct CONNECT + :protocol=websocket admission, stream-local cancellation/backpressure, sibling-stream survival, and no HTTP/1 Upgrade-field emulation;
7. prove HTTP/3/RFC 9220 separately; no H3/QUIC support or cutover credit exists until the selected runtime exposes and verifies it;
8. exact-head formatting, compile/test, strict Clippy, warning-denied rustdoc, 100% owned-production line+region coverage, realistic concurrency/load/failure traffic, OCI, Supply/Security and current-range review remain mandatory;
9. after an immutable gateway release, each consumer owner must still prove its own parity → shadow/canary → observed rollback → cutover → legacy-proxy removal. This issue can only supply reusable transport capability.

DDD ownership remains in HTTP Policy / Runtime Isolation / Ingress delivery / Observability. WebSocket application authorization, subprotocol business meaning, tenant/session policy, product timeout choices and deployment rollback remain product-owned.

Keep this issue open and status: blocked until supplier release authority and the complete reusable transport acceptance are GREEN. The newly settled #113 receipt removes uncertainty about whether the 0.9.0 RED is reproducible; it does not remove the blocker.

[seonghobae]

Owner-path projection is now current in dedicated documentation lane #61. Ordinary-forward 407414eab07b77af4771795b2033d75e55999e62 adds #112 to docs/product-technical-gap-baseline.md; 2034d07ae730b0a452ed9fa5255041a35ce1da8b adds the corresponding supplier/standards rows and APA-7 references to repository-wide docs/doctoring/TRACEABILITY.md.

Fresh authority recheck used for that projection:

• protected cloudflare/pingora/main@4487f7b2ab50f159e4a2cf4f6a6b813f61bb6e19 is unchanged;
• upstream #946 remains open with the fast-101 / empty-request-body scheduler race;
• contributor #947 remains open/unmerged at 1e8488b0627370831832744fc6e65614396c310d;
• latest public release remains Pingora 0.9.0 (published 2026-09-09), with GitHub release metadata immutable=false and zero attached assets;
• RFC 9931 (March 2026) is now explicitly traced together with RFC 6455/8441/9220, keeping H1 Upgrade, H2 Extended CONNECT, and H3 Extended CONNECT as separate acceptance contracts.

No WebSocket capability, supplier patch, timeout default, product route/auth policy, or production Rust was added. #112 remains blocked until a maintainer-integrated release-qualified supplier identity exists and the real-wire acceptance in this issue can run unchanged.

[seonghobae]

Owner path advanced with Draft PR #113 (test/websocket-fast-101-supplier-red-v1) on released-supplier parent #70@df5d2f05fc5fbdd94bbfb487283bf2a6d73a55bf.

#113 adds an executable real-wire H1 supplier RED rather than enabling WebSocket. The fixture starts a loopback origin, a child Pingora proxy using the exact parent dependency (pingora = 0.9.0) with HttpUpstreamRequestPolicy::standard() only in test scope, and a raw downstream client. It delays request-body processing by 200 ms to force the fast-101 ordering documented by upstream #946/#947, waits 300 ms after receiving 101 Switching Protocols, then requires cwl-fast-101 to traverse the upgraded tunnel and echo back. Production deny_upgrades() remains unchanged.

Focused source/evidence commits are 568b6bbea839caf49ec7faec3516a15ce4d0f8e6 (real-wire RED) and f49c2e979f847d0904fe1705f0af2b0c74afea6d (issue-scoped evidence note). Fresh compare against #70 is ahead 2 / behind 0 with exactly two added paths: tests/websocket_fast_101_supplier_red.rs and docs/doctoring/WEBSOCKET_FAST_101_SUPPLIER_RED.md.

The PR stays Draft because #70 itself is Draft with the known stale-foundation readiness RED. No hosted RED/GREEN is claimed until foundation/release ancestry is reconciled and normal execution is available. Supplier authority is still blocked: protected Cloudflare main remains 4487f7b2...; #947 remains open/unmerged at 1e8488b.... No mutable supplier pin, implementation patch copy, product policy, H2/H3 claim, or cutover credit was introduced.

[seonghobae]

#113 was tightened before hosted execution: current exact is now 85141378dd038be0d4aae2b446a596f532b36013. Follow-up 3663137666aa6793174144a88e84a8bdb8d84a06 upgrades the RED from raw tunnel bytes to a valid RFC 6455 exchange: fixed sample key/Sec-WebSocket-Accept, masked client FIN text frame, origin-side unmask/validation, and unmasked server FIN echo. 85141378... updates the focused evidence note accordingly.

This narrows the future GREEN claim: the fast-101 lane must survive an actual WebSocket opening handshake and post-handshake frame exchange, not merely pass arbitrary bytes after a 101. Production deny_upgrades() and #112's remaining H2/H3/backpressure/disconnect/drain gates are unchanged. No workflow run is currently associated with the new exact head; the earlier f49c2e9... queued receipts are stale and receive no credit.

[seonghobae]

#113 current exact is now 8ebe0cd4093bbcc5d1951ed38f982a044eb58e93, ordinary ahead 6 / behind 0 from #70 with only the focused test + evidence note effective paths. The latest fixture also makes startup evidence retry-safe: transient pre-ready connect/read failures no longer abort the characterization, but readiness still requires a complete /readyz HTTP 200; realistic traffic keeps strict absolute read deadlines.

Current-head CI 35340553428, Supply 35340553410, and pg-erd capacity 35340553411 have been created. CI jobs load-contract 105585238328, test 105585238694, and oci-runtime 105585238713 are all pre-runner queued with no steps/runner yet, so no hosted RED/GREEN is credited. Previous branch-head receipts remain stale.

[seonghobae]

Fresh H2 supplier-source pass narrows the RFC 8441 gate further. Protected Pingora main@4487f7b2... does parse Extended CONNECT as a distinct request shape (CONNECT + :protocol + :path) in pingora-core/src/protocols/http/v2/server.rs, but default_h2_options() only sets bounded header-list/concurrent-stream limits and does not call the underlying h2::server::Builder::enable_connect_protocol(). Pingora re-exports that builder as H2Options, so an application can potentially opt in, but default H2 listener behavior is not evidence that RFC 8441 SETTINGS_ENABLE_CONNECT_PROTOCOL=1 is advertised.

This keeps #112's H2 contract fail-closed: no H2 WebSocket capability credit until an exact gateway listener explicitly opts in, the SETTINGS exchange is observed on wire, :protocol=websocket Extended CONNECT is accepted only under that setting, stream-local bidirectional DATA/backpressure/cancellation is proven, and sibling streams survive. This is separate from #113's H1 fast-101 supplier RED; do not infer H2 support from H1 standard() or from generic parser awareness.

[seonghobae]

#113의 current-head review에서 supplier RED 자체와 무관한 fixture-integrity finding을 유효로 확인해 수리했습니다. 75a42783b26c31e52d3f5325de395e2cf392ff93에서 child process cleanup guard를 /readyz 대기 전에 설치하고, listener reservation을 child command 구성까지 유지한 뒤 spawn 직전에만 해제하며, origin accept() thread는 readiness 성공 뒤에 시작하도록 옮겼습니다. Focused doctoring은 4f540478f6bd455d459ed00dd31bc9ab7e3fd186에 기록했습니다. CodeRabbit Major thread는 exact change 검증 후 resolved/outdated 상태입니다.

#113 current exact는 4f540478f6bd455d459ed00dd31bc9ab7e3fd186, parent #70 대비 ordinary ahead 8 / behind 0이며 effective paths는 계속 test fixture + issue-scoped doctoring 두 개뿐입니다. 새 exact CI 35341928903, Supply 35341928926, bounded-origin capacity 35341928975는 queued이고 CI jobs는 모두 pre-runner(steps=[], runner 없음)라 hosted RED/GREEN은 아직 부여하지 않습니다. Production deny_upgrades(), Pingora 0.9.0 pin, fast-101 200 ms ordering control, 300 ms post-101 settle, RFC 6455 frame oracle은 변경하지 않았습니다.

Supplier authority도 변하지 않았습니다: upstream #946 open, #947 open/unmerged at 1e8488b0627370831832744fc6e65614396c310d. 따라서 #112의 release-qualified maintainer integration → unchanged real-wire acceptance → remaining backpressure/disconnect/drain/H2/H3 순서는 그대로입니다.

[seonghobae]

#113 current-head review found a second fixture-integrity defect independent of the supplier race. The frame readers previously set a five-second socket timeout and then used multiple read_exact() calls for prefix/mask/payload, so slow partial progress could renew the per-read timeout and stretch a single frame beyond the intended five-second evidence budget. This was weaker than the same fixture's absolute-deadline header reads.

Ordinary repair d3ad47b860d35efc3a4803d327a4c01d1791a6cc gives each client/server WebSocket frame one absolute deadline and every partial read only the remaining duration. Follow-up f01e9b14df1e861f18b84615b7d4fe9c4785fd4c preserves read_exact()-equivalent retry handling for interrupted system calls and does not treat an early rounded timeout/would-block as terminal before the absolute deadline actually expires. Focused evidence is current at c80fcce0a8c0d312acedfeaeeb331d7c1d65509f.

The fast-101 200 ms ordering control, 300 ms post-101 settle, RFC 6455 masking/payload oracle, Pingora 0.9.0 dependency, and production deny_upgrades() boundary are unchanged. This is fixture evidence-boundedness only, not a product/gateway timeout policy.

#113 remains Draft on #70 ancestry. Fresh exact CI 35344931974, Supply 35344931880, and pg-erd capacity 35344931952 are queued; no hosted RED/GREEN transfers from earlier heads. Supplier authority is also unchanged: protected Pingora main remains 4487f7b2..., #947 is still open/unmerged at 1e8488b0.... WebSocket enablement remains blocked on release-qualified supplier disposition plus the remaining #112 transport acceptance.

[seonghobae]

Current supplier-RED handoff correction: #113@c80fcce0a8c0d312acedfeaeeb331d7c1d65509f has now left the queue. Supply Chain 35344931880 and bounded-origin capacity 35344931952 completed SUCCESS; CI 35344931974 failed only at Rust 1.98.0 cargo fmt --all -- --check. OCI and load-contract were SUCCESS, while compile/test/Clippy/rustdoc/coverage/lock steps were skipped after formatting. Hosted rustfmt output was applied verbatim as ordinary successor #113@0de545694ed52b9c9367d00b2748eece9d750276; compare is ahead 1 / behind 0 and touches only tests/websocket_fast_101_supplier_red.rs (+20/-29 formatting). Fast-101 ordering, RFC 6455 oracle, frame/header deadlines, Pingora identity and production deny_upgrades() are unchanged. Fresh exact runs are CI 35385248424, Supply 35385248406, capacity 35385248377 and are pending/queued; no old receipt transfers. #112 therefore remains fail-closed and blocked on exact-head characterization plus release-qualified supplier authority.

[seonghobae]

Fast-101 supplier child transition: #113 exact 0de545694ed52b9c9367d00b2748eece9d750276 finally acquired runners. Supply 35385248406 and bounded-origin capacity 35385248377 succeeded; CI 35385248424 failed only at Rust 1.98.0 formatting in test job 105730559346, while OCI 105730559079 and load 105730559348 succeeded. The formatter log contained exactly two remaining layout rewrites in the supplier-only fixture (prefix[0], 0x81, on one line). Ordinary successor 26dea63a60a1961edfe4cb7f2f0a0da096aa5b7c applies only those two deltas; current review 5253788866 found no semantic change. Fresh exact CI 35409928073, Supply 35409928080, capacity 35409928052 are materialized. Production WebSocket remains fail-closed; no supplier-repair or enablement credit.

[seonghobae]

Current executable-evidence update from #113. Exact 26dea63a60a1961edfe4cb7f2f0a0da096aa5b7c finally received runners: Supply 35409928080, bounded-origin capacity 35409928052, CI OCI 105807343621, and CI load 105807343835 were GREEN, while CI test 105807343713 passed checkout/Rust 1.98.0/rustfmt and failed at ordinary Compile and test. The supplier RED was still an auto-discovered integration test, so ordinary cargo test --all-targets --locked --no-fail-fast mixed a known affected-supplier RED into repository CI.

#113 now repairs that evidence boundary without enabling Upgrade or copying the supplier fix. Ordinary-forward commits 5bcdaed9359d3f207fbeedaa29e4f2e7f1b0c5ee and 76c9cfc6af55ab80dfa1514dd8e24278cbec4ea7 gate only websocket_fast_101_supplier_red behind empty-default supplier-red and add a dedicated exact-SHA characterization workflow; 79d9bd512a0f6f6165a8dac9bf5c3f87751080a1 binds focused doctoring, and current exact fbad4e031927b0a92adc7244224d2bfdaba7d513 records the hosted RCA. The workflow proves the ordinary all-target graph excludes the RED, compiles the gated target explicitly, and credits only a bounded post-101 tunnel-teardown fingerprint. An unexpected GREEN makes the RED receipt invalid rather than being silently accepted. Production deny_upgrades(), Pingora 0.9.0, RFC 6455 oracle, deadlines, and consumer-owned timeout/auth/routing semantics are unchanged.

Fresh hosted runs for fbad4e... still need to materialize/settle, and parent #70 remains stale/Draft. Therefore #112 stays blocked: this is an executable supplier-characterization repair, not WebSocket capability or release/cutover credit.