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 #3147
Check · Review · Land · Live done — Landed and live in production.
The forge-webspec fetcher now goes through the same seam production uses, `compress(request, response)` and then `securityFloor`, and `compression` is gone from the known list. All 3 tests in `test/forge-webspec.test.ts` pass and `bun x tsc --noEmit` is clean. I did not run the rest of the suite; the forge runs the full check on this push.
shipped production is serving it deploy 3b6d43c
The forge-webspec fetcher now goes through the same seam production uses, compress(request, response) and then securityFloor, and compression is gone from the known list. All 3 tests in test/forge-webspec.test.ts pass and bun x tsc --noEmit is clean. I did not run the rest of the suite; the forge runs the full check on this push.
- Fetcher: it sets
accept-encoding: br, gzipunless the caller already supplied one, which webspec does. Aftercompress, it decodes the br or gzip body but leaves theContent-EncodingandVaryheaders in place. That mirrors what a realfetchdoes, so webspec can read the page text and still check the headers. - Known list:
WHYis removed andKNOWNis now an empty map. Thecompressionentry had been listed as "set at the edge", and no compression finding remains on any of the 7 walked pages. - Small bodies: webspec's rule already exempts them (
encodingProblemsreturns nothing underCOMPRESS_MIN), sosrc/release/webspec.tsandtest/webspec.test.tsare unchanged.
To try it: bun test test/forge-webspec.test.ts.
Test-only change. The fetcher now runs compress then securityFloor, the same order as src/http/server.ts, and decodes the body while keeping Content-Encoding for webspec to read. The stale compression entry is gone from KNOWN. test/forge-webspec.test.ts passes (3 tests). No runtime, security or UI surface changed, and the README needs nothing. Two things I would do next: (1) Add a small assertion that at least one walked page actually comes back with content-encoding br or gzip. Otherwise the compression check could pass vacuously if every page fell under MIN_BYTES. (2) Export the compress-then-floor pipeline from one place that both server.ts and this test import. Then the test cannot drift from production order.
The full gate on land was red and named no test; the pull is open again.
The forge-webspec fetcher now goes through the same seam production uses,
compress(request, response)and thensecurityFloor, andcompressionis gone from the known list. All 3 tests intest/forge-webspec.test.tspass andbun x tsc --noEmitis clean. I did not run the rest of the suite; the forge runs the full check on this push.accept-encoding: br, gzipunless the caller already supplied one, which webspec does. Aftercompress, it decodes the br or gzip body but leaves theContent-EncodingandVaryheaders in place. That mirrors what a realfetchdoes, so webspec can read the page text and still check the headers.WHYis removed andKNOWNis now an empty map. Thecompressionentry had been listed as "set at the edge", and no compression finding remains on any of the 7 walked pages.encodingProblemsreturns nothing underCOMPRESS_MIN), sosrc/release/webspec.tsandtest/webspec.test.tsare unchanged.To try it:
bun test test/forge-webspec.test.ts.Closes #3144