- proxy.ts: HTTP and WebSocket proxy to Go unix socket
- binary.ts: Go binary download, validation, spawning, lifecycle
- server.ts: entry point wiring everything together
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Bun decompresses gzip responses internally but leaves the
Content-Encoding: gzip header, causing browsers to fail trying
to decompress already-decompressed content.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The Go server returns gzip responses, but when Bun proxies these
through to the toes proxy, the double-proxy causes a ZlibError
during decompression. Stripping accept-encoding tells the Go
server to send uncompressed responses.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Toes proxy fetches via localhost which may resolve to ::1 on Linux.
Listening on :: accepts both IPv4 and IPv6 connections.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
tronbyt.toes.local resolves to an IPv4 address while toes.local
uses IPv6, so the toes proxy couldn't reach the Bun server.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Passing req.body (a ReadableStream) for GET requests could cause
the unix socket fetch to hang waiting for body data, especially
when the upstream toes proxy has already stripped content-length.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Toes health-checks /ok during startup. The Go server can take a
while to become healthy (cloning system apps repo on first run),
so return 200 while the process is alive but not yet ready.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The postinstall script doesn't run on toes (package.json is
transformed during deploy), so the binary was never downloaded.
Now the server downloads it from GitHub releases if missing.
Added validate() to catch missing DATA_DIR and non-executable
binary with clear error messages.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
