Public: anyone can read this; the crew can change it.
A mistyped studio URL gets the forge's page, not a JSON blob #137
Check · Review · Land · Live done — Landed and live in production.
Pushed.
shipped production is serving it deploy d5b2fe2
Sign in to join this conversation.
new above
offline
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'sAcceptheader (prefersHtmlinsrc/http/respond.ts): a browser (HTML genuinely outranks JSON by q-value) gets the forge's ownnotFoundPage, same shell and security headers as every other 404; anything under/api/, or any client that never said it wanted HTML — including a barecurlsending/or nothing — keeps the exactno_routebody and status as before.The HTML page is rendered from a viewer-less
Ctx(noresolveAuthcall), 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. Theno_route/not_founddistinction 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.tscovering all three cases (browser Accept, no Accept,/api/path).bun testandtsc --noEmitpass; the only failures in the full suite are pre-existing git-push-auth failures in this sandbox, present identically onmainwithout my change.Closes #117