From 7226e70b8aa62dfab223d32ec38c7906ff095869 Mon Sep 17 00:00:00 2001 From: Jaap-Jan de Wit | DodoTech Date: Wed, 29 Jul 2026 13:27:12 +0200 Subject: [PATCH] Record that a sub-path server URL is silently dropped MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Found while sweeping for the stale default. The client uses the typed address only as HttpClient.BaseAddress and every request path is root-absolute, so https://example.test/dodossh reaches https://example.test/api/v1/... with the prefix discarded and no error — which rules out hosting under a sub-path, the usual arrangement behind a proxy fronting several services. The server already publishes a canonical apiBaseUrl the client could normalise against and ignores. Recorded rather than fixed: it is a deployment-shape decision, not a bug in the screen that prompted this. --- docs/platform-flags.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/platform-flags.md b/docs/platform-flags.md index a93038e..a891e02 100644 --- a/docs/platform-flags.md +++ b/docs/platform-flags.md @@ -270,6 +270,15 @@ publish when resolving `localhost` — so every realm request returned 404 while looked healthy. If discovery fails against a locally-published container, check for another process bound specifically to loopback before suspecting the container. +**A path prefix in the server URL is silently discarded.** The client uses the typed address only as +`HttpClient.BaseAddress` and every request path is root-absolute (`/api/v1/meta`, +`/.well-known/dodossh-configuration`, …), so `https://example.test/dodossh` reaches +`https://example.test/api/v1/...` and the prefix is dropped without a word. That rules out hosting DodoSSH +under a sub-path — which is exactly what a reverse proxy in front of several services usually does. Nothing +trims or normalises the typed URL either, and it is the raw string, not the parsed form, that becomes the +local cache's identity. The server already publishes a canonical `apiBaseUrl` in its discovery document +that the client could normalise against and currently ignores. + **`Sync:CursorSigningKey` generates an ephemeral per-process key when unset.** Fine for a single node; on a multi-node deployment cursors issued by one node are rejected by another, so clients resync from the beginning repeatedly. Must be configured explicitly before running more than one