Problem
While reviewing the Quint spec's routing table against all three implementations (issue #5), found a cross-language inconsistency in how container names are extracted from the URL path.
Rust (rs/src/proxy.rs) and TypeScript (ts/src/proxy.ts) both explicitly exclude reserved path segments (create, json, exec) from being treated as a container name when parsing /containers/:name/... paths. Go's extractContainerName (go/internal/proxy/router.go) does not.
Concretely: a request like DELETE /containers/json is treated as Allow (unknown-container passthrough) in Go, but falls through to Deny (default-deny) in Rust and TypeScript, because Rust/TS recognize json as a reserved segment rather than a container name.
Impact
Low severity — not exploitable as a privilege escalation on its own (the request would still need to pass all other gates), and not exercised by the Quint model (which doesn't model this specific parsing edge case). But it's a real behavioral difference between the three "equal peer" implementations that could cause confusing/inconsistent behavior depending on which language a deployment uses.
Solution
Update go/internal/proxy/router.go's extractContainerName to exclude the same reserved segments (create, json, exec, and any others Rust/TS already exclude) that Rust and TypeScript already handle, so all three implementations agree on which path segments are container names vs. reserved routing keywords.
Which implementation(s) would this affect?
Additional context
Found during the Quint spec review in #5. Confirmed via gh api diff of Router implementations, not by direct testing — recommend adding a unit test case for DELETE /containers/json (and similar) across all three languages once fixed, to catch regressions.
Problem
While reviewing the Quint spec's routing table against all three implementations (issue #5), found a cross-language inconsistency in how container names are extracted from the URL path.
Rust (
rs/src/proxy.rs) and TypeScript (ts/src/proxy.ts) both explicitly exclude reserved path segments (create,json,exec) from being treated as a container name when parsing/containers/:name/...paths. Go'sextractContainerName(go/internal/proxy/router.go) does not.Concretely: a request like
DELETE /containers/jsonis treated asAllow(unknown-container passthrough) in Go, but falls through toDeny(default-deny) in Rust and TypeScript, because Rust/TS recognizejsonas a reserved segment rather than a container name.Impact
Low severity — not exploitable as a privilege escalation on its own (the request would still need to pass all other gates), and not exercised by the Quint model (which doesn't model this specific parsing edge case). But it's a real behavioral difference between the three "equal peer" implementations that could cause confusing/inconsistent behavior depending on which language a deployment uses.
Solution
Update
go/internal/proxy/router.go'sextractContainerNameto exclude the same reserved segments (create,json,exec, and any others Rust/TS already exclude) that Rust and TypeScript already handle, so all three implementations agree on which path segments are container names vs. reserved routing keywords.Which implementation(s) would this affect?
Additional context
Found during the Quint spec review in #5. Confirmed via
gh apidiff of Router implementations, not by direct testing — recommend adding a unit test case forDELETE /containers/json(and similar) across all three languages once fixed, to catch regressions.