Browser session cookie is keyed by authority: ~70 cookies overflow the 16KB header limit (431, UI looks dead)

[ylluminatey]

Summary

dsh-client-connection names its browser-session cookie after the request authority:

const COOKIE_PREFIX = "dsh-auth-";
function cookieName(authority) {
  return COOKIE_PREFIX + encodeBase64Url(createHash("sha256").update(authority).digest());
}

…with Max-Age = 30 days. Nothing ever removes cookies belonging to authorities that are no longer used, so every distinct host:port the user opens keeps its own cookie for a month. When the jar grows large enough, the request Cookie header exceeds Node's default maxHeaderSize (16 KB), the server answers 431, and the UI simply looks dead ("DSH 崩了").

Measured

Against a local DSH server (DSH 0.2.1-rc.2, Windows 11, Node 24.13.0), sending N synthetic dsh-auth-* cookies:

cookies	avg value	Cookie header	response
10	100 B	1.2 KB	401 (expected, no ticket)
30	100 B	3.6 KB	401
70	100 B	8.4 KB	401
70	300 B	22.4 KB	431 Request Header Fields Too Large
70	600 B	43.4 KB	431

Real signed cookie values are a few hundred bytes, so a jar of ~70 entries is enough to cross the 16 KB header limit. This matches the community report "cookie 堆满 70 条左右就崩".

Why the jar grows that fast

Cookie identity is the authority, so any of these leaves a new, never-collected cookie:

• DSH Desktop / Electron launching on a random port each run
• reaching the same server as 127.0.0.1:3080, localhost:3080, a LAN IP, a Tailscale IP, or the remote-access port
• changing --port or the remote-access port over time

Suggested fixes

1. Reuse a single cookie name (e.g. fixed dsh-auth + distinguishing Path), or delete/rewrite cookies whose authority no longer matches the current listener at startup.
2. Sweep stale cookies: when the server starts, expire any dsh-auth-* cookie whose authority is not the current bind/trusted host. The client can also prune them from document.cookie before setting a new one (values are HttpOnly, but the server can send Set-Cookie with Max-Age=0 for stale names it knows about in the request).
3. Cap the header: either bump --max-http-header-size in the shipped launcher, or return a friendly error page instead of a bare 431.

Workaround applied locally

NODE_OPTIONS=--no-network-family-autoselection --max-http-header-size=65536

That makes 70 × 600 B headers pass; it does not stop the cookie from accumulating.

Environment

• DSH 0.2.1-rc.2 (web profile), Windows 11, Node v24.13.0
• Chrome (cookie jar at %LOCALAPPDATA%\Google\Chrome\User Data\Default\Network\Cookies)
• Reproduced with plain node:http requests, no plugins involved