3 Commits

Include renames

Author	SHA1	Message	Date
retoor	6514261730	Route container proxies through the leg that is actually reachable ... The workspace editor hung for 60s and then 504'd. Three independent faults were stacked behind that one symptom. Reachability: editor_target delegated to proxy_target, which returns CONTAINER_PROXY_HOST plus the published host port and never falls back to the container. From inside the app container that address crosses docker0 into the host INPUT chain, whose policy is DROP with an allow-list that does not include the published port range, so the packet was dropped and the request hung rather than being refused. Measured from the app container: container_ip:8443 answers 302, gateway:20006 is dropped. One shared reachable_target now prefers the direct container leg and falls back to the published port, and editor_target uses tunnel_target as services/containers/CLAUDE.md already required. The same defect affected /p/{slug} ingress and every tunnel, since all three resolved through proxy_target. The recorded measurement that motivated the old order (container_ip times out, gateway connects) no longer holds: make docker-attach puts the app on the instances' bridge network, which is what makes the direct leg work. Duplicate response headers: the forwarding core relayed the upstream Date and Server alongside the ones the serving layer generates, so every proxied response carried two of each. Both are singleton headers and duplicating them is malformed HTTP. Serialization: WorkspaceViewOut declared flag_reason and three sibling strings as str, so a NULL column made the workspace page 500 for JSON clients. Documents the two public hostnames and the devplace.net SSH tunnel, so a future session does not conclude the site is down after pointing curl --resolve at an address the hostname does not resolve to, and adds the layered procedure for diagnosing a production failure. Verified on production with Playwright over both hostnames: the code-server login renders and the workbench loads. Suite: 3345 passed.	2026-08-13 12:59:53 +02:00
retoorandClaude Opus 5	c0742994cd	Make the workspace editor reachable through the sub-path proxy ... code-server runs authenticateOrigin on every websocket and resolves the request host as Forwarded, then X-Forwarded-Host, then Host. The forward core put the public host into additional_headers, but the websockets client already writes its own Host for the real TCP target and Headers appends, so the handshake carried two Host lines; Node keeps the first (the internal gateway:port), the origin check failed, and code-server answered 403. Because the browser socket was accepted before the upstream was dialled, that surfaced as a 101 followed by 1011 and the editor died on "the workbench failed to connect to the server". Dialling first and carrying the public host in the connect URI fixes both planes. The two header builders that had drifted apart are now one core, so a websocket carries the same client and forwarded headers as an HTTP request. Responses stream instead of buffering whole, which is what makes a large tunnel download cost constant memory and lets SSE work; byte accounting moved onto the completion callback. Subprotocols negotiate, the upstream client is reused across requests, and the path and query are forwarded byte-exactly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-09 11:26:17 +02:00
retoor	21f6ae0615	iUUUUpdatexz	2026-08-07 10:53:43 +02:00