route-proxy serves a route's internal-name alias, never certifies it #61

2026-09-25T15:24:31Z

jschoubben commented

2026-09-25 15:24:31 +00:00

A route now consumed with two hosts when the mesh composed both — the same host under internal-name reaches the same rule as its public name, restoring the convenience a predecessor proxy gave for reaching a service over the VPN without a public TLS round trip (the field composeName now writes, #60).

Never certified: onlyWhatTheMeshSaid used routed(), which answered yes for any host in the table regardless of how it got there. A new eligibleForACME() checks a parallel public set instead — every host reached through a route's own name, never one reached only through its internal-name — so an internal alias is proxied but never given its own failing ACME order. routed() is unchanged and still used for the 404 message, which legitimately wants "is this host served at all."

Rebased onto #60. Full suite passes except the three pre-existing TestTheBuildersCarriedPackageBinding* failures (hq issue 117, unrelated).

A route now consumed with two hosts when the mesh composed both — the same host under `internal-name` reaches the same rule as its public name, restoring the convenience a predecessor proxy gave for reaching a service over the VPN without a public TLS round trip (the field `composeName` now writes, #60). Never certified: `onlyWhatTheMeshSaid` used `routed()`, which answered yes for any host in the table regardless of how it got there. A new `eligibleForACME()` checks a parallel `public` set instead — every host reached through a route's own `name`, never one reached only through its `internal-name` — so an internal alias is proxied but never given its own failing ACME order. `routed()` is unchanged and still used for the 404 message, which legitimately wants "is this host served at all." Rebased onto #60. Full suite passes except the three pre-existing `TestTheBuildersCarriedPackageBinding*` failures (hq issue 117, unrelated).

jschoubben added 1 commit 2026-09-25 15:24:31 +00:00

route-proxy serves a route's internal-name alias, never certifies it 6da55bdfea

A route now consumed with two hosts when the mesh composed both — the
same host under internal-name reaches the same rule as its public name,
restoring the convenience a predecessor proxy gave for reaching a service
over the VPN without a public TLS round trip (the field composeName now
writes, feat/route-carries-internal-alias — this branch depends on that
one landing for internal-name to ever be populated; builds and tests
clean without it, just serves nothing extra).

Never certified: onlyWhatTheMeshSaid used routed(), which answered yes
for any host in the table regardless of how it got there. A new
eligibleForACME() checks a parallel 'public' set instead — every host
reached through a route's own name, never one reached only through its
internal-name — so an internal alias is proxied but never given its own
failing ACME order. routed() is unchanged and still used for the 404
message, which legitimately wants 'is this host served at all.'

jschoubben merged commit 7bf23ea052 into main

2026-09-25 15:24:37 +00:00

jschoubben deleted branch feat/route-proxy-serves-internal-alias

2026-09-25 15:24:37 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-controller#61