docs(http): add ADR-043 WebTransport bidirectional ALPN substrate; fix spec drift from mid-spec pivot

A consistency review of the alknet-http specs found two classes of
issues: internal contradictions from the mid-spec pivot (the to_openapi
gateway pattern landed in prose but not in cross-references), and a
systematic client→server assumption that only holds for the OpenAPI/MCP
case leaking into the WebTransport architecture.

Class 1 (internal contradictions):
- C1: to_openapi was half-refactored — body described the ADR-042
  gateway pattern but the decisions table and ADR-036 still said
  'paths mirror /{service}/{op}'. ADR-036's to_openapi clause is now
  amended as superseded by ADR-042; the stale decisions row and README
  Principle 2 are fixed.
- C2: the axum Router route list didn't include the 5 gateway endpoints
  (/search, /schema, /call, /batch, /subscribe). Added them; clarified
  /openapi.json as the gateway description doc; added gateway paths to
  the decoy exclusion list.
- C3: ADR-034 §5 still talked about the 'h3/WebTransport deferral
  bucket' that ADR-038 eliminated. Amended §5/Consequences/References
  to drop the deferral framing (the auth-model decision stands; only
  the 'when' wording was stale).

Class 2 (one-way direction assumption):
- C4/C5/C6: the WebTransport specs framed the session as browser→hub
  one-way, when the call protocol is bidirectional and WebTransport is
  a general ALPN transport substrate. New ADR-043 reframes WebTransport
  as a bidirectional ALPN transport substrate (call protocol is the
  first/canonical target; needs no WASM parser), names the call
  protocol's bidirectionality over WebTransport sessions, and states
  the inbound no-PeerId connection-local overlay as the mirror of
  ADR-034 §2. webtransport.md is updated to reflect this framing;
  ADR-040 is repositioned (not superseded) as the substrate's non-call-
  ALPN mechanism.
- C7: the HTTP/1.1+HTTP/2 surface's one-directionality is now named as
  a lossy consequence of HTTP request/response; WebTransport is named
  as the surface that restores the bidirectional call model.
- C8: overview.md acknowledges the from/to direction model is
  OpenAPI/MCP-specific, not a call-protocol property.

A review subagent pass on ADR-043 + webtransport.md found no critical
issues; warnings W1-W3 (residual browser-as-subject framing, ADR-009
rationale in spec, opening abstract tone) and suggestions S2/S4/S5
were addressed.
This commit is contained in:
2026-06-29 10:43:18 +00:00
parent 69ebe58bab
commit 0a78306686
10 changed files with 660 additions and 85 deletions

View File

@@ -40,8 +40,14 @@ WebTransport stream. So the browser:
The hub's `h3` handler needs to hand that WebTransport stream to the
target ALPN handler (e.g., `SshAdapter`) as if it were a QUIC stream
arriving on that ALPN. The `h3` handler becomes an **ALPN-stream-proxy**:
a browser-side gateway that gives browsers access to any ALPN handler
via WebTransport.
a WebTransport-client-side gateway (browser or otherwise) that gives
WebTransport clients access to any non-call ALPN handler via WebTransport.
> Repositioned by [ADR-043](043-webtransport-bidirectional-alpn-substrate.md)
> §4: the proxy is the substrate's mechanism for non-call ALPNs (SSH,
> git, SFTP) that need a client-side parser, distinct from the call
> protocol which speaks EventEnvelope directly and needs no proxy. The
> browser is the primary use case; the decision (the `HandlerRegistry`
> reference, path-based routing) is unchanged.
### Why this matters
@@ -275,6 +281,10 @@ Two layers, same as a native `alknet/ssh` connection.
- [ADR-038](038-http3-and-webtransport-as-first-class.md) — `h3` is
first-class (this ADR adds the ALPN-stream-proxy as the third stream
destination)
- [ADR-043](043-webtransport-bidirectional-alpn-substrate.md) §4 —
repositions this ADR's framing: the proxy is the substrate's mechanism
for non-call ALPNs (not the browser's gateway to every ALPN). The
decision stands; the framing is refined.
- `crates/http/webtransport.md` — the spec that implements this proxy
- `crates/core/endpoint.md``HandlerRegistry` (the registry the
`h3` handler gains a reference to)