Problem
The three implementations disagree on DELETE /containers/ (empty segment in the container-name position) — same family as #24, opposite direction:
- Go (
go/internal/proxy/router.go, extractContainerName): returns "", which is falsy → request falls through to default-deny (403).
- TypeScript (
ts/src/proxy.ts, extractContainerName): returns undefined → default-deny (403).
- Rust (
rs/src/proxy.rs, extract_container_name): returns Some("") → the lifecycle DELETE branch treats the empty string as a container name → unknown-container passthrough → Allow, and the request is forwarded to the Docker daemon.
Found during the merge-gate review of #43 (which fixed the Go side of #24; this divergence is pre-existing and not introduced there).
Impact
Low severity, same reasoning as #24: the daemon answers 404 for an empty name, so this is not exploitable on its own. But it is a real behavioural divergence between the "equal peer" implementations, and a request Go and TypeScript refuse to forward reaches the daemon when the deployment runs the Rust proxy.
Proposed solution
rs/src/proxy.rs::extract_container_name should return None for an empty name segment, matching Go/TS. Add the same test case in all three languages (DELETE /containers/ → 403) plus an integration check, so the row is pinned the way #43 pinned the reserved segments.
Alternatives considered
Which implementation(s) would this affect?
Go and TypeScript get regression tests only; behaviour changes in Rust alone (convergence to the majority/deny behaviour, consistent with the equal-peers rule).
Problem
The three implementations disagree on
DELETE /containers/(empty segment in the container-name position) — same family as #24, opposite direction:go/internal/proxy/router.go,extractContainerName): returns"", which is falsy → request falls through to default-deny (403).ts/src/proxy.ts,extractContainerName): returnsundefined→ default-deny (403).rs/src/proxy.rs,extract_container_name): returnsSome("")→ the lifecycle DELETE branch treats the empty string as a container name → unknown-container passthrough → Allow, and the request is forwarded to the Docker daemon.Found during the merge-gate review of #43 (which fixed the Go side of #24; this divergence is pre-existing and not introduced there).
Impact
Low severity, same reasoning as #24: the daemon answers 404 for an empty name, so this is not exploitable on its own. But it is a real behavioural divergence between the "equal peer" implementations, and a request Go and TypeScript refuse to forward reaches the daemon when the deployment runs the Rust proxy.
Proposed solution
rs/src/proxy.rs::extract_container_nameshould returnNonefor an empty name segment, matching Go/TS. Add the same test case in all three languages (DELETE /containers/→ 403) plus an integration check, so the row is pinned the way #43 pinned the reserved segments.Alternatives considered
Which implementation(s) would this affect?
Go and TypeScript get regression tests only; behaviour changes in Rust alone (convergence to the majority/deny behaviour, consistent with the equal-peers rule).