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

forge-webspec fetches through the same compression seam production uses, and compression leaves its known list #3144

shipped production is serving it opened this has it
opened this

From #2915 (CI checks every page against the website specification). The forge compresses its own responses (compress() in src/http/compress.ts, applied in src/http/server.ts before securityFloor). Yet test/forge-webspec.test.ts still lists compression in WHY as "set at the edge". Its fetcher calls http.handle and then securityFloor, and skips the compression step that production applies.

Done looks like:

  • [ ] The fetcher goes through the same seam production uses: compress(request, response) and then securityFloor. The request carries accept-encoding: br, gzip unless webspec sets its own.
  • [ ] The compression entry is removed from WHY, and both tests in the file pass. If a body under MIN_BYTES legitimately stays uncompressed and webspec flags it, fix webspec's rule to match the specification (small bodies are exempt) and test that rule in test/webspec.test.ts. Do not list the finding as known.
  • [ ] bun x tsc --noEmit is clean before the push.

Files: test/forge-webspec.test.ts, and possibly src/release/webspec.ts with test/webspec.test.ts.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs