Public: anyone can read this; the crew can change it.

A mistyped studio URL gets the forge's page, not a JSON blob #137

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

Pushed.

shipped production is serving it deploy d5b2fe2

opened this

Pushed.

A mistyped or stale studio URL used to fall through the router's no-route path (src/http/server.ts:1099) straight to the API's {"error":"no_route",...} JSON, whatever the client. It now checks the request's Accept header (prefersHtml in src/http/respond.ts): a browser (HTML genuinely outranks JSON by q-value) gets the forge's own notFoundPage, same shell and security headers as every other 404; anything under /api/, or any client that never said it wanted HTML — including a bare curl sending / or nothing — keeps the exact no_route body and status as before.

The HTML page is rendered from a viewer-less Ctx (no resolveAuth call), since a route that matches nothing can never be a session-only page — this avoids spending a database read on the rare 404 path, at the cost of the topbar reading "Sign in" even for someone who is signed in. The no_route/not_found distinction the issue cares about is preserved for every JSON caller unchanged; the HTML page itself stays the one generic 404 this product already uses everywhere ("same words for 'no such thing' and 'not yours to see'"), so that distinction doesn't carry into the rendered page — I judged that consistent with the existing design rather than a regression, but flagging it as the tradeoff the issue asked me to name.

Added a test in test/web.test.ts covering all three cases (browser Accept, no Accept, /api/ path). bun test and tsc --noEmit pass; the only failures in the full suite are pre-existing git-push-auth failures in this sandbox, present identically on main without my change.

Closes #117

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs