dsh web: keepAliveTimeout (5 s default) still unfixed in 0.2.1-rc.2 — independent reproduction and verified fix

[dimitree2k]

Continues #2270, which was closed as Q&A on 2026-08-16 with no answer and no code change. The bug is still
present in the newest published package: @deepseek-ai/dsh-host-webserver@0.2.1-rc.2 (npm tag next)
contains zero occurrences of keepAliveTimeout, and createServer is still called without any timeout
configuration.

Summary

On a high-latency link (~300 ms RTT) the browser cannot complete the WebSocket upgrade to /api/remote.mux.
The UI stays on "reconnecting" and chats never load. On the server side nothing is visible: no request
line, no status code, no log entry, because the handshake dies before the request is read. This makes the
failure expensive to diagnose — the browser-trust fence, cookies, TLS, the reverse-proxy shape and
Tailscale/DERP were all verified innocent first.

Reproduction

1. dsh --profile web --port 3080 --tls-cert … --tls-key … on a host reachable over a high-latency path.
2. Expose it through an L4 forward, e.g. tailscale serve --bg --tcp 3080 tcp://127.0.0.1:3080.
3. From a client at ~200–400 ms RTT load the UI, let the connection go idle, then reload.
4. Browser console: repeated WebSocket connection to 'wss://…/api/remote.mux' failed: The network connection was lost.

Server-side proof: strace -f -p <pid> -e trace=read shows zero GET /api/remote.mux reads over 90 s
while ordinary HTTP traffic keeps flowing. Probes that always open a fresh connection (curl,
http.request) upgrade fine — the failure only occurs on connection reuse.

Current behavior

• Upgrade fails repeatedly, UI stuck on "reconnecting".
• Server logs nothing.
• Response headers: Connection: keep-alive, Keep-Alive: timeout=5.

Expected behavior

The upgrade succeeds when the browser reuses a connection it had kept idle, and the session stays stable.

Analysis

Matches #2270: createServer() / createServer$1() in @deepseek-ai/dsh-host-webserver set neither
keepAliveTimeout nor headersTimeout, so Node's 5 000 ms default applies. Browsers keep idle keep-alive
connections and reuse them for the upgrade; at ~300 ms RTT the server's FIN has not arrived yet.

Fix verified locally (immediately before this.server.listen(...)):

this.server.keepAliveTimeout = 65000;
this.server.headersTimeout = 66000;

Result: Keep-Alive: timeout=65, three live mux sessions exchanging ping traffic (~120 bytes per 8 s), and
no reconnects across 90-second windows and a 120-second single-connection hold — with two different
browsers (Safari and Firefox).

Additionally useful for a fix: making both values configurable on the webserver entry, and defaulting
keepAliveTimeout well above 5 000 ms, since deployments behind a proxy/NAT are exactly the ones that hit it.

Environment

• DSH 0.2.1-rc.2 (npm global), Node 22.22.1
• Raspberry Pi 5, aarch64, Linux 6.12
• dsh --profile web --port 3080 --no-open --trusted-host <tailnet-name> --tls-cert … --tls-key …
• Transport: tailscale serve --bg --tcp 3080 tcp://127.0.0.1:3080 (L4, no L7 proxy)
• Clients: macOS, Safari and Firefox, RTT ~300 ms

[PerryLink]

Still unfixed on master as of 22ddee3. keepAliveTimeout appears zero times in the tree, and both constructions — packages/host/webserver/src/index.ts:566 (http) and :575 (https) — pass only the listener and the TLS options. Your rc.2 finding carries forward unchanged.

One placement detail worth adding: set both fields once after the if/else (:566-:583) and before listen() (:621). The TLS branch reassigns this.server after the plain branch has already assigned it, so a setting placed only inside tls === undefined leaves exactly the deployments in your reproduction (--tls-cert / --tls-key) unfixed.

On the values, 65 s / 66 s is right — Node documents that headersTimeout should be above keepAliveTimeout, and the 5 s default is what expires the idle connection the browser is about to reuse for the upgrade. Going much above 65 s mainly delays reclaiming sockets; the point is only to outlive the client's idle window.

Your "nothing in the log" observation also follows from the code: upgrades are served by the 'upgrade' listener at :584, and a socket the server already FINed never reaches it — no request line, no status, nothing to log.