No signed-in page or API answer can be stored by a shared cache, and immutable assets are cached for a year: a test checks both #5914

A signed-in page or API answer can no longer carry public or s-maxage, and a new test checks that along with the asset headers. The new test passes and the type check is clean. I ran only the suites that touch cache headers, not the whole check. In those, the chromium look tests fail in this sandbox and a releases.json count is off by one (expected 101, got 100). I didn't investigate either.

What was wrong. Signed-in /asked and /forges answered a bare no-cache, which a shared cache may still store. A private issue's API answer carried no Cache-Control at all.

Fix. A new privateWhenSignedIn in src/http/respond.ts runs after the security floor on every answer. If the request carried a cookie or Authorization, the answer leaves private, with public and s-maxage removed. immutable assets are left alone, since a browser sends its cookie for them too.

Test. test/cache-private.test.ts requests:

• as a signed-in admin: /, a private repo, a private issue page, /asked, /forges, /api/v1/feed and the private issue's API answer, and checks each is private or no-store with no public or s-maxage;
• the shell script, stylesheet and toolbar script, and checks each answers public, max-age=31536000, immutable.

It also pins down the one signed-out answer that stays cacheable, /opensearch.xml (public, max-age=3600), and says why. The content-addressed assets are cacheable too. It unit-tests the stripping rule as well.

Existing test changed. test/web.test.ts expected no-cache on the signed-in home. It now expects private, no-cache, because the old value was the bug.

Left out. I did not audit signed-out HTML pages individually. They stay no-cache or no-store, and none is asserted public. Responses from the app proxy keep their own headers.

Closes #5899

A signed-in page or API answer can no longer carry public or s-maxage, and a new test checks that along with the asset headers. The new test passes and the type check is clean. I ran only the suites that touch cache headers, not the whole check. In those, the chromium look tests fail in this sandbox and a releases.json count is off by one (expected 101, got 100). I didn't investigate either.

What was wrong. Signed-in /asked and /forges answered a bare no-cache, which a shared cache may still store. A private issue's API answer carried no Cache-Control at all.

Fix. A new privateWhenSignedIn in src/http/respond.ts runs after the security floor on every answer. If the request carried a cookie or Authorization, the answer leaves private, with public and s-maxage removed. immutable assets are left alone, since a browser sends its cookie for them too.

Test. test/cache-private.test.ts requests:

• as a signed-in admin: /, a private repo, a private issue page, /asked, /forges, /api/v1/feed and the private issue's API answer, and checks each is private or no-store with no public or s-maxage;
• the shell script, stylesheet and toolbar script, and checks each answers public, max-age=31536000, immutable.

It also pins down the one signed-out answer that stays cacheable, /opensearch.xml (public, max-age=3600), and says why. The content-addressed assets are cacheable too. It unit-tests the stripping rule as well.

Existing test changed. test/web.test.ts expected no-cache on the signed-in home. It now expects private, no-cache, because the old value was the bug.

Left out. I did not audit signed-out HTML pages individually. They stay no-cache or no-store, and none is asserted public. Responses from the app proxy keep their own headers.

I merged main into the branch, resolved the one conflict in src/http/server.ts, and pushed.

The conflict was in the final response step. main added a WWW-Authenticate bearer challenge on /api/v1/ 401s. My side routed every response through privateWhenSignedIn, which makes signed-in answers private. The merged code does both: add the challenge, then compress, apply the security headers and privateWhenSignedIn.

I ran test/cache-private.test.ts and test/web.test.ts (54 pass, 0 fail). The type check and the full bun test ran in the background for over ten minutes without finishing here. I stopped waiting and left the full check to the forge's run on this push.