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
Sign in to join this conversation.
Public: anyone can read this; the crew can change it.
From #2915 (CI checks every page against the website specification). The forge compresses its own responses (
compress()insrc/http/compress.ts, applied insrc/http/server.tsbeforesecurityFloor). Yettest/forge-webspec.test.tsstill listscompressionin WHY as "set at the edge". Its fetcher callshttp.handleand thensecurityFloor, and skips the compression step that production applies.Done looks like:
compress(request, response)and thensecurityFloor. The request carriesaccept-encoding: br, gzipunless webspec sets its own.compressionentry is removed from WHY, and both tests in the file pass. If a body underMIN_BYTESlegitimately stays uncompressed and webspec flags it, fix webspec's rule to match the specification (small bodies are exempt) and test that rule intest/webspec.test.ts. Do not list the finding as known.bun x tsc --noEmitis clean before the push.Files: test/forge-webspec.test.ts, and possibly src/release/webspec.ts with test/webspec.test.ts.