Add a compression.test.ts case for unsupported Accept-Encoding values

[Jagadeeshftw]

📌 Description

Per the README, responses are gzip-compressed when the client sends Accept-Encoding: gzip and the body is large enough to benefit. src/compression.test.ts likely covers the gzip-accepted case, but not what happens when a client sends an encoding the server doesn't support (e.g. Accept-Encoding: br only, no gzip/identity) — it should gracefully fall back to an uncompressed response, not error.

🧩 Requirements and context

• Add a test sending Accept-Encoding: br (and no gzip) against a large response body, asserting a successful, uncompressed (identity) response rather than an error.
• Add a test for Accept-Encoding: gzip;q=0 (explicitly disallowed) similarly falling back cleanly.
• No production code changes expected unless the tests reveal a real gap in src/app.ts's compression wiring.

🛠️ Suggested execution

• Extend src/compression.test.ts with the unsupported/disallowed-encoding cases.
• If a gap surfaces, adjust the compression middleware configuration in src/app.ts.

✅ Acceptance criteria

• Requests with an unsupported Accept-Encoding still receive a valid, uncompressed response.
• q=0-disallowed gzip falls back cleanly.
• No regression to the existing gzip-accepted path.

🔒 Security notes

No new attack surface; ensures compression negotiation can't produce request failures.

📋 Guidelines

• Minimum 95% test coverage
• Clear documentation
• Timeframe: 96 hours

[GBOYEE]

Hi maintainers, I can handle this one (Add a compression.test.ts case for unsupported Accept-Encoding values). I'll fix the bug with tests and open a PR. Happy to coordinate if anyone's already looking at it.

[grantfox-oss]

🦊 GrantFox — @GBOYEE has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #101)
2. Your PR will be reviewed by the AnchorNet-Org maintainers

Good luck! Track your progress on GrantFox.