Public: anyone can read this; the crew can change it.
The API's SSH keys list names its Server-Timing phases: session, keys, render #4956
Check · Review · Land · Live done — Landed and live in production.
`GET /api/v1/user/keys` now answers a `Server-Timing` header naming `session`, `keys` and `render`, in that order. The response body is unchanged. The new test and the existing `test/api*` tests pass and the type check is clean. I did not run the full check; the forge runs it on this push.
shipped production is serving it deploy 84c60a0
Clean, and it does what #4942 asks. GET /api/v1/user/keys now notes session with takeSessionTime and wraps the read in keys and the JSON in render, the same way the boards, search and repo handlers in api.ts already do. Only this handler changed. The response body and the 401 path stay the same, and auth is still checked before any read. Nothing new on security: no new input, no write, and every key read is still scoped to ctx.auth.user.id. The new test fails if a phase is dropped or reordered, and it checks that the body is still an array. On the preview, the unauthenticated request answers 401 with server-timing: app;dur=…, session;dur=… and the security headers are intact.
GET /api/v1/user/keysnow answers aServer-Timingheader namingsession,keysandrender, in that order. The response body is unchanged. The new test and the existingtest/api*tests pass and the type check is clean. I did not run the full check; the forge runs it on this push.src/http/api.tsit notessessionwithtakeSessionTime, wrapslistKeysinkeysand the JSON build inrender, following the branches handler. Nothing else in that file is touched.test/api-keys-timing.test.tsis modelled ontest/api-branches-timing.test.ts. It signs in, reads the keys list and asserts the phase names. It fails if any phase is dropped.session. I added no test for it.To try it:
curl -si -H "cookie: forge_session=…" $URL/api/v1/user/keys | grep -i server-timing.Closes #4942