serve.zone/dcrouter
3
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 4 Wiki Activity

4 Releases 585 Tags

RSS Feed
  • v34.5.0 f42a05c26b
    Compare

    DcRouter v34.5.0
    Release / build-and-release (push) Successful in 15m27s
    Details
    Stable

    jkunz released this 2026-11-11 11:47:23 +00:00 | 0 commits to main since this release

    2026-11-11 - 34.5.0

    Features

    • Request headers on gateway-client routes (gateway clients, ops API). syncGatewayClientRoute accepts route.action.requestHeaders (@serve.zone/interfaces 32.75.0): header fields dcrouter sets on every request and WebSocket upgrade the route forwards, validated by the shared validateGatewayRouteRequestHeaders (lowercase names, no field dcrouter owns on the backend leg such as host, hop-by-hop fields, x-forwarded-*, proxy-* or sec-websocket-*, at most 16 fields; a refusal names fields, never a value) and stored as the SmartProxy route's headers.request, which replaces every copy of a name the client sent, on WebSocket upgrades too (@push.rocks/smartproxy 27.22.1). A gateway client hands its backend a trusted-proxy secret this way. A route with route.action.tls.mode: 'passthrough' or route.match.transport: 'udp' is refused with request headers: SmartProxy forwards a passthrough TLS stream unread, and a UDP-only route's traffic never reaches its HTTP service, so they would never be set. The values are write-only: each sync states the complete set (a sync without it removes them), getGatewayClientRoutes lists only requestHeaderNames, and every route listing (RouteConfigManager.getMergedRoutes: ops getMergedRoutes, the Ops UI, MCP, gateway reads) takes headers.request off a gateway-client route and lists the names in IMergedRoute.requestHeaderNames; operator routes are listed as before. The stored route keeps the values, so a failed sync's rollback restores them. getGatewayCapabilities answers routes.requestHeaders: true. The values sit in the route database as SmartProxy applies them.
    • Source profile names in gateway-client route reads (gateway clients). getGatewayClientRoutes answers sourceProfileName next to sourceProfileRef (@serve.zone/interfaces 32.75.0), both from the same source binding: the profile name dcrouter recorded when the route was synced, so a client reads the binding back by the name it synced. A binding stored without a name answers the id alone.
    • Data version 34.5.0 and its way back (migrations, CLI). The gateway-route-request-headers step changes nothing on the way up; dcrouter 33.0.0 through 34.4.0 refuse to start on its ledger. dcrouter migrate --to 34.0.0 deletes the request headers of every gateway-client route in one transaction with the ledger stamp (operator routes keep theirs) and logs each route and its field names, never a value, so dcrouter 34.0.0 through 34.4.0 never list one. Nothing keeps the values: after upgrading again, each gateway client's next full sync sets them again. From 34.5.0 data, --to 32.6.0 runs this step first and then the route DNS ownership restore; each commits on its own, so a refusal of the second leaves the data at 34.0.0.

    Maintenance

    • Restore sha512 integrity for 22 pnpm-lock.yaml entries (once, wrappy, etag and other old packages) that a Verdaccio resolve had recorded as sha1 in the 34.0.0 tooling update; each value is npmjs's and matches the tarball both registries serve.
    • Release tooling: @git.zone/tsrepo 1.1.1 → 2.0.0, @git.zone/tsdocker 3.13.0 → 3.14.0, @types/node 26.6.5 → 26.6.6 and pnpm 12.14.0 → 12.17.0 (12.18.0 does not yet meet the seven-day rule). tsrepo 2.0.0 makes @push.rocks/smartmongo an optional peer. No dcrouter test calls createSmartmongo(), so smartmongo, @lossless.org/nosqldb and the rest of tsrepo's former subtree are gone from the install. @git.zone/tsdeno stays on 1.15.0 until lane D5 of the Deno-removal programme moves build:binary off it. The runtime dependency versions are unchanged; the only change in the production closure is the type-only @types/node, which resolves to 26.6.6 alone (it was 26.6.2 and 26.6.5). Seven sha1- lockfile entries written by the Verdaccio resolve are restored to npmjs's sha512.
    Downloads