fix: set Vary: Accept-Encoding for preCompressed responses

[LeSingh1]

What

When preCompressed is enabled, the response variant is selected from the request Accept-Encoding header (brotli, then gzip, then the uncompressed original). The handler set content-encoding accordingly but never set Vary: Accept-Encoding, so the response did not declare that it depends on that request header.

This is the issue reported in #230. Without Vary: Accept-Encoding, a shared cache can store one variant and serve it to a client that negotiates a different one, for example handing a brotli body to a client that did not send Accept-Encoding: br, or returning the uncompressed fallback to a client that does accept compression.

Change

The file branch now adds Vary: Accept-Encoding whenever preCompressed is enabled. It is added for the uncompressed fallback too, since that response is still the result of content negotiation and a cache must key on the encoding to stay correct.

A small addVaryAcceptEncoding helper reads the current vary value from the raw response so a header already set through setHeaders is preserved, appends accept-encoding only when it is not already present, and leaves an existing Vary: * untouched. Nothing changes when preCompressed is disabled.

Tests

Added cases under test/static.test.js:

• sends Vary: Accept-Encoding when serving a compressed file
• sends Vary: Accept-Encoding when falling back to the uncompressed file
• appends to an existing Vary header set via setHeaders, including an array value, without duplicating accept-encoding
• does not append to an existing Vary: *
• does not send the header when preCompressed is disabled

npm run lint passes and the new tests pass. The README preCompressed section documents the behavior.

Closes #230

[LeSingh1]

Heads up on the red CI: the only failing job is Test (24, macos-latest), and the single failure there is the pre-existing "with fastify-compress" test timing out after 30s because it reaches out to the network. All seven of the new Vary: Accept-Encoding tests pass on that same run, and every other OS and Node version is green. The timeout is unrelated to this change, so a re-run should clear it.

[LeSingh1]

Thanks for the feedback. Both points are addressed in the latest commit.

For the first comment, I switched from reply.raw.getHeader to reply.getHeader so the Vary header is read through the fastify reply API rather than dropping to the raw response object.

For the second comment, I replaced the split/some pattern with a plain for loop that walks the comma-separated tokens directly by tracking a start index. No array is allocated and no split call is made. The logic is otherwise the same: if accept-encoding or * is already present, we bail out early; otherwise we append accept-encoding at the end.

All 327 tests still pass with 100% coverage.

[mcollina]

lgtm